The Org Check Comes Before the Quote
Every Salesforce estimate given before someone has opened the org is a guess dressed up as a number. Here is what half a day of looking actually turns up, and why the findings are so consistent.
A prospect describes their org for thirty minutes. You have a picture in your head by minute five, and a number by minute twenty.
That number is a guess. Not an informed one, either. It is built entirely out of what somebody chose to tell you, and the thing about a Salesforce org that has been running for six years is that nobody in the building knows all of it. The admin who set up the sharing model left in 2023. The person describing the problem joined last spring. They are giving you an honest account of an org they have only ever seen from one angle.
So we look first. Half a day, read access, no commitment either way.
What gets looked at
Six things, in this order, because that is roughly the order in which a wrong answer gets expensive.
The data model.Not whether it is tidy. Whether it still matches the business. Most orgs were shaped correctly for the company that existed when they were built, and have been absorbing new requirements ever since by adding fields to whatever object was closest. The question is not "is this clean", it is "how many of your open requests are fighting a decision made in 2019".
Sharing and visibility.Who can see what, against who is supposed to. In every org that has been running a few years, these two lists disagree. Usually it is harmless. Occasionally it is a compliance finding waiting for someone to run the report.
Automation overlap.Flow, Process Builder and Apex all writing to the same record, with no rule anywhere about which one wins. Teams know this is happening. What they usually cannot tell you is the order things fire in, which means nobody can predict what a new automation will do until it does it.
The release path.How a change reaches production, and what actually happens when one has to come back out. I ask for the rollback story specifically. If the answer involves a person, a Friday and a careful mood, that is the finding.
Drift and dependencies.What has been changed directly in production, outside the pipeline. There is always something. Then the other half: what quietly breaks if you retire a field that looks unused. "Looks unused" is doing a lot of work in that sentence, and a dependency trace settles it in minutes.
Limits and API versions.The ceilings you are approaching before anyone gets an alert, and the components still pinned to an API version Salesforce has already announced the retirement of.
Why the findings are so consistent
I used to think this repetition meant the teams were careless. It does not. It means the incentives are identical everywhere.
Every one of those six items is invisible until it fails. None of them is what anyone is measured on. An admin who spends a sprint untangling automation order has, from the outside, shipped nothing, and an admin who adds the requested field has shipped something. Run that for four years and you get the org I am describing, staffed entirely by competent people.
That is also why an outside check finds things the team could have found themselves. It is not skill. It is that somebody finally got paid to go looking.
## The tooling is public, and that is the point
We run this with the same tooling we publish. Drift detection, dependency tracing, API version audits and limit pressure are all commands in SFDT, which is open source, and the Chrome extension puts most of the same checks in the browser against an org you are already logged in to.
So there is a version of this you can run yourself, today, without hiring anybody. I would rather you did. A client who has already seen their own drift report is a much better conversation than one being shown a surprise.
The catch
A check is not free, and it is not neutral.
It costs real time, and it will sometimes conclude that the thing you asked for is not the thing you need, which is an awkward result to deliver and an awkward one to receive. It has twice ended with me telling someone their org was fine and their problem was a process one. Neither of those became projects. Both of them were the correct finding.
It also cannot tell you about the things that only show up under load, or under a user who does something nobody anticipated. Half a day of reading gets you the structural picture. It does not get you the incident you have not had yet.
What it does get you is an estimate built on the org instead of on the conversation.
One thing to try this week
Pick the field you are most confident is unused. The obvious one, the one everybody agrees is dead.
Trace what references it before you delete it. Flows, formulas, reports, page layouts, Apex, integrations. Then tell me the number was zero.
