Ten years of decisions nobody wrote down.
A rebuild here starts with reading. We retrieve the org and map what fires, what is dead, and what is broken. We cut the dead part and rebuild the rest on a base your admins can run.
What we find
In almost every org
- Fields nothing reads. They still load on every page layout and land in every export, and nobody dares delete them.
- Three generations of automation on one object. Workflow Rules, Process Builder, Flow, and Apex triggers fire on the same save, in an order nobody can state, so a fix in one breaks another.
- Hard-coded record IDs. A Flow or a formula points at one record by ID, which works in production and fails in every sandbox and every migration.
- Profiles that drifted from permission sets. Access was granted by hand for years, so two people with the same job see different fields, and nobody can say why.
- Validation rules that fight flows. A rule blocks the save a Flow is trying to make, the error reads like a code, and users learn a workaround instead of reporting it.
- Reports nobody opens. Thousands of reports, most not run in a year, and the three that matter are copied instead of fixed.
- Integrations with no owner and no error handling. A nightly job fails, nothing alerts, and the first sign is a customer asking where their order went.
- Sandboxes that no longer match production. The last refresh was three releases ago, so a change that passes in test still breaks on deploy.
- Managed packages installed for one feature. Each one brought its objects, its triggers, and its license, and the feature was dropped when its sponsor left.
- Data that skewed when a picklist was renamed. The value changed, the old records did not, and every report since shows two rows for one thing.
How a rebuild runs
Four stages, in order
01 Survey
We read the org before we touch it. We retrieve the metadata with the Salesforce CLI and read it as source, in a repository, not in Setup. We measure field usage from the data, so a field is dead because nothing reads it, not because nobody remembers it. We draw an automation map per object: every rule, process, Flow, and trigger that fires on a save, in order. We read the last year of support tickets, because they say what breaks for real.
You get a written read of what is broken, what it costs you, and what we would do about it.
02 Route
We agree on the order of work. The read becomes three lists. The keep list is what works and stays. The kill list is what nothing uses and goes. The rebuild list is what is broken and worth fixing, in the order it pays off. Each cycle on the rebuild list has a cost next to it.
You approve the cost of each cycle before we start it. No cycle starts without a number you have seen.
03 Build
We ship in short cycles from a repository. Every change is source: it lives in the repository, is built in a scratch org or a clean sandbox, and is deployed, not clicked. Access runs on permission sets, not profiles. Automation runs in Flow where Flow fits and in Apex where it does not. Lightning Web Components cover what the standard UI cannot. Data migration is scripted and validated on both sides, with counts and samples, before any cutover.
You use each cycle as it lands. Nothing waits for a launch.
04 Hand over
Your team owns the org. You get the repository, the runbook, the data dictionary, and training for your admins on how the org works now and why. The last cycle is yours: your team ships it, and we watch.
Then we leave, and nothing depends on us.
Score your org
Two minutes, no email
These eight questions are the first read we do in a survey. Answer them yourself. Nothing leaves your browser unless you send it.
The read
Answer the eight questions. The read appears here.
- Stable base
- The base holds. Anything flagged here is a fix, not a rebuild.
- Worth a survey
- Something costs your team time every week. A survey finds out how much, and what to cut first.
- Rebuild candidate
- The org works against your team. The survey still comes first, and it will likely route to a rebuild.
The band comes from the weights, not the count. Two heavy answers outweigh three light ones.
Where we would start
What we work in
Salesforce
- Sales Cloud
- Service Cloud
- Experience Cloud
- Government Cloud
- Health Cloud
- Integrations
- Apex
- Lightning Web Components
- Flow
- Data migration
We also rebuild the systems around the org. The integrations. The spreadsheets that became a system of record. The middleware nobody can restart. If it feeds Salesforce or reads from it, it is in scope.
Questions we get
Answered plainly
Do we need to rebuild from scratch?
No. Most of the org stays. The survey sorts it into what works, what is dead, and what is broken. We delete the dead part and rebuild the broken part. The rest we leave alone, because it does its job.
A full re-implementation is rare. When it is the right call, the survey says so, with the reason.
Will our users have to stop working?
No. We ship in short cycles, and each one is usable the day it lands. There is no freeze and no big launch. A data cutover is planned with you, rehearsed in a sandbox, and run in a window you pick.
Do you work with our existing admin?
Yes. Your admin knows the history, and the survey goes faster with them in the room. The handover assumes them. The runbook and the training are written for the person who runs the org after we leave.
Do you need production access?
Read access to start. The survey retrieves metadata and reads data, and it changes nothing. Where your data rules require it, the reads run in a sandbox with masked data, and the metadata we retrieve lives in a repository you own.
After that, every change goes through a repository and a sandbox. Production changes are deployed, not clicked. We do not build in production Setup.
What about Government Cloud or Health Cloud?
We work in both, with the same method. The survey also reads the compliance constraints your org already carries, such as who may see what and where data may go, and the rebuild keeps them.
We do not claim a certification we do not hold, and we do not work around a constraint to ship faster.
How do you price it?
The survey is a fixed, small engagement with a fixed price. It ends with the written read and the three lists. Every cycle after it has a number you approve before we start, and no cycle starts without one.
Start here
Tell us what your org does wrong.
Say what fails, who feels it, and how often. We answer in one business day with a first read and the shape of a survey.