Every project we have ever had to rescue went wrong before the first line of code. Not in the architecture, not in the framework choice — in the scoping. Somebody agreed to build something before anyone had written down what it was, and every argument that followed was really the same argument: we never decided what we were building.
So this is what we actually do before we quote, in the order we do it. I run these calls myself, with one of our business analysts alongside, and the process below is the process — not a brochure version of it.
The first call is about your operation, not your idea
Most people arrive with a solution. "We need a portal." "We want an AI chatbot." The idea is sometimes right, and we still put it aside for the first half hour, because a solution proposed before the problem is understood is a guess wearing confidence.
What we ask about instead: where the hours go in a normal week, what gets done twice, what breaks when volume rises, what you have already tried. The answers usually point somewhere — and about a third of the time they point somewhere other than the thing we were asked to build.
That third matters. When the answers say the portal is really an invoicing problem, we say so on the call. Occasionally that costs us a project. It costs less than building the wrong thing and being the firm whose name is on it.
Where AI earns its place, and where it does not
Because we build AI systems, people expect us to recommend them. The honest version: AI earns its place where the work involves reading messy input, making routine judgments at volume, or finding patterns a person cannot hold in their head. Document intake, triage, matching, drafting. It does not earn its place as a chat interface bolted onto software that needed a better form.
On the call we go through each candidate feature and ask one question: what happens when it is wrong? If a wrong answer is caught by a person in the loop and costs seconds, AI fits. If a wrong answer reaches a customer or a ledger unreviewed, it needs a different design or it does not belong. Deciding this before scoping is what keeps the AI parts of a build from becoming the expensive parts.
What gets written down
The call ends in a document, not a feeling. Ours has four parts, and none of them is optional:
What we are building. Named screens, named workflows, named integrations. "A dashboard" is not a scope; "a dispatch board showing today's jobs by crew, with drag reassignment" is.
What we are not building. The explicit exclusions. This section prevents more disputes than every other section combined, because most scope arguments are about something each side silently assumed.
What it connects to. Every system yours has to talk to, with a note on how — API, export, or a person retyping. Integration is where estimates die; naming the connections up front is how ours survive.
What correct means. For anything with AI in it, the measure we will evaluate against before it ships. If we cannot state the measure, we do not ship the feature.
The price is fixed after this, not before
We quote after the document exists, and the quote is fixed against it. Changes are welcome — they arrive as written changes with their own price, rather than as drift that surfaces in month three as a dispute.
If a firm quotes you before anything like this exists, the number is a placeholder. It has to be. Nobody can price what nobody has defined — they can only start the relationship with a number designed to be revised.
What to bring if you want this to go fast
You do not need a specification. The useful things are: whoever actually does the work day to day (not only their manager), examples of the documents or data involved, and honesty about what has already failed. One operator with real examples moves a scoping call further than five stakeholders with opinions.
The call costs you thirty minutes and the document is yours either way. If we are not the right firm for the build, the scope still is — take it to whoever is.
- scoping
- discovery
- procurement
- custom-software
- process