For an architecture decision that needs to become a working org
Salesforce Implementation
An architecture decision on paper is worth nothing until reps are actually working inside it, and most implementations fail at the desk, not in the sandbox. This practice takes an agreed plan, whether ours or someone else's, and builds a Salesforce org people use instead of route around.
How a Salesforce build stays adopted after go-live
Configuration in working slices, migration with an owner, and training that lands.
90 secSample frame · video pending01Before writing a single flow
Declarative or custom code is a real trade-off
Custom Apex gets reached for too quickly, usually because it is what an available developer already knows. Four questions settle it against your actual requirement.
Can a Flow or validation rule do this?
Declarative tools now cover most business logic that used to need Apex, and they are far cheaper for your team to maintain later.
Does the logic depend on complex external data?
Apex earns its cost when logic needs to call an external API or handle volumes declarative tools cannot process cleanly.
Who maintains this after we leave?
An admin can adjust a Flow. Custom Apex needs a developer, which changes your long-term support cost meaningfully.
Is there a vetted AppExchange package already?
Buying a maintained package sometimes beats building custom logic your team will own forever, especially for common capabilities.
| Declarative (Flow, rules) | Custom Apex | |
|---|---|---|
| Who can maintain it | A trained admin | A developer |
| Best for | Standard business logic | Complex or external-data logic |
| Change speed | Fast, low risk | Slower, needs testing |
| Long-term cost | Lower | Higher, ongoing |
02Agreed before configuration starts
The ledger that keeps a build honest
Implementation engagements drift when scope is assumed rather than written down against the architecture. This ledger fixes what you bring, what we build, what returns, and what stays under your control throughout.
- Your side
You bring
- A written architecture decision or an agreed set of requirements
- Sample data or access to the legacy system it replaces
- The teams and process the org needs to support
- Our side
We build
- Objects, automation and page layouts configured against the plan
- Custom Apex and Lightning Web Components where declarative tools fall short
- A migration of legacy records into the new structure
- Your side
You receive
- A production org configured to the agreed architecture
- Trained users working the org for their actual process
- A support handbook for the admin who inherits it
Never leaves you
- The org, its data and every configuration inside it
- The Salesforce contract and licence assignment
- The roadmap for what gets built next
Where the line sitsWe configure to the plan; you own the org the moment it goes live. Nothing here creates a dependency on us to keep running.
03From plan to adopted org
Four stages, each closing on a working slice
Salesforce builds that stall usually skipped a stage here. This system closes each one with something reps could actually log into and use.
Configure one process at a time
Each increment configures a single sales or service process end to end, so acceptance happens per slice rather than at one distant launch.
Objects and automation, scoped tightlyMigrate data with an owner
Every migrated object is mapped, deduplicated and reconciled against a named business owner before it counts as done.
Records with a name attachedIntegrate and test under real conditions
Connections to surrounding systems are built and load-tested before go-live, not discovered under pressure afterward.
Connections that survive loadTrain, launch and measure adoption
Training and usage dashboards carry the change into daily work, and the engagement closes on usage evidence, not a launch date.
Reps working the process daily
04What actually moves the number
Four drivers, priced from the scoped plan
Salesforce implementation is priced against the architecture already agreed, because these four factors change build effort by multiples.
Amount of custom Apex required
A build that stays inside declarative tools costs meaningfully less than one requiring extensive custom development.
Volume and quality of data to migrate
Clean records from one source migrate quickly. Records across several legacy systems with duplicates take considerably longer.
Number of systems needing integration
A standalone org configures faster than one that must stay synchronised with finance, support and marketing systems.
Number of teams needing training
A single sales team trains faster than a rollout spanning sales, service and partner-facing teams at once.
05Evidence and proof
Orgs reps stopped working around.
Implementation proof is deals worked inside the platform and migrations that lost nothing in transit. Every record here waits for written client approval before production.
Explore case studies
A quoting process rebuilt around how reps actually sell.
Vela Ledger's reps priced deals in spreadsheets beside an underused Sales Cloud org. Reconfiguring the quoting flow around their real steps brought pricing back inside the platform.
- Quotes created in-platform
- 9 in 10
- Quote turnaround time
- Two days to same-day
A legacy CRM migrated with zero lost pipeline.
Aster North needed five years of legacy CRM history moved into a new Salesforce org without losing a single open deal in transit.
- Open deals lost in migration
- Zero
- Records reconciled and owned
- All migrated objects
The org actually matches how we sell now. Nobody keeps a shadow spreadsheet anymore, and that alone changed the pipeline reviews.
Sample · pending client approval
06Read this first
When implementation is the wrong first move
Starting a build before the architecture question is settled produces expensive rework later. The exits are marked plainly. When implementation is justified, it runs on standard Salesforce tooling, sandboxes and version control for Apex and metadata.
- Salesforce Consulting
The edition or architecture is still undecided
Configuring against an unsettled decision means rebuilding once the real decision lands. Settle the architecture first.
- Team extension
You need developers, not a delivery team
If your admin already owns the roadmap and just needs Apex capacity, team extension fits better than a commissioned build.
- System integration
The real blocker is systems, not Salesforce itself
When the pain is other platforms failing to sync with Salesforce, system integration is the more direct fix.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Architecture and scope are already agreed | Priorities and rollout pace | Configuration and delivery |
| Delivery pod | Requirements will keep evolving | Product decisions each cycle | Engineering and testing |
| Team extension | Your admin owns the roadmap | Standards and architecture | Named engineers and continuity |
07Straight answers
Asked before a Salesforce build kicks off.
01How is this different from Salesforce consulting?
Consulting decides the edition, architecture and build-versus-buy calls. This practice takes that decision and builds it: configuration, custom code, migration and training. If the architecture is not yet decided, consulting comes first.
02Do you write custom Apex or only configure declaratively?
Both, chosen against the requirement rather than habit. Declarative tools cover most needs and cost less to maintain, so Apex is reserved for logic they genuinely cannot handle.
03How long does a Salesforce implementation take?
The first fully working process typically ships inside a quarter, because slicing by process keeps each increment small enough to finish and adopt before the next one starts.
04What does Salesforce implementation cost?
Pricing follows the scoped process slices from the agreed architecture, with custom Apex, migration volume and integration count as the main variables. Licence cost is modelled separately from delivery cost.
05Can you migrate our data without losing open deals?
Yes, every migrated object gets a named owner and a reconciliation report before go-live, and open pipeline gets verified record by record rather than in aggregate.
06Can you work alongside our existing Salesforce admin?
Yes, and an admin who knows the org's history is an asset during the build, not a complication. We slot delivery around whatever they already maintain.
07What happens to custom code during a Salesforce release upgrade?
Apex and Lightning components get built against supported patterns and tested ahead of seasonal releases, so an upgrade stays routine maintenance instead of a fire drill.
08Do you handle integrations with other systems during the build?
Yes, integration setup with the systems around Salesforce is scoped and load-tested as part of the same engagement rather than left for a separate project.