Data model and sharing
Objects, relationships, record types and the sharing model, designed against how the business actually works rather than how the first demo was configured.
Sharing is the one thing that is genuinely painful to change later: it constrains reporting, integration and every automation that follows.
A model that answers the questions the business will ask.
Sales, Service and Experience
Whichever clouds are in scope, configured against your process: pipeline stages that mean something, case routing that matches the rota, portals that do not duplicate the internal UI.
Standard functionality is used until it demonstrably cannot do the job. Every departure from it is recorded with the reason.
A build a new admin can read.
Automation
Flow for the orchestration, Apex only where Flow genuinely cannot reach, and a single documented path per process rather than four overlapping ones.
Orgs accumulate workflow rules, process builders and flows that all fire on the same object. Consolidating that is most of the work on a rescue engagement.
One automation per process, not four.
Data migration and quality
Extraction, cleansing, deduplication and load, with reconciliation reports the business signs off rather than a row count from the loader.
Migrating dirty data on schedule is the most common way a good build loses its users in month one.
Users who trust what they see.
Permissions and access
Profiles, permission sets and roles built as a deliberate structure, with least privilege as the starting position rather than the cleanup task.
Permission debt is invisible until an audit or an AI feature starts surfacing records somebody should never have seen.
An access model you can explain.
Adoption and handover
Training by role rather than by feature, admin documentation written during the build, and a defined period of hypercare after go-live.
A build nobody can change without us is a dependency we do not want to sell you.
Your team owning the org, not renting it.