Fixed-quote software work is mostly a way to lose money unless you scope well. AI projects are worse because the unknowns are structural, not just technical.
We lost money on three projects in 2024 learning this. We have not since. This is the scoping process we use now, documented as honestly as we can make it.
The three questions that decide whether a project ships on time
Before we quote a fixed price on any AI build, we ask these three questions of ourselves, in writing, before the client call.
1. What is the smallest thing we could ship that would prove or disprove the bet?
"We want to use AI to route customer support" is a goal, not a project. The project is: a router that classifies an inbound email into one of six buckets and forwards it to the right team, with a reversible fallback to the existing manual process. That is shippable in six weeks. "Use AI to route support" is not. If the smallest shippable thing is not obvious, we keep reducing until it is.
2. Which data does this model need, and do we have a clean pipeline to it?
This is the question that catches us out most often. A client will say they have "five years of tickets". What they mean is five years of tickets across three systems, in three formats, with no consistent schema, behind three different auth flows. If the discovery exposes that the data pipeline is the project and the model is the easy part, we say so and rescope.
The rule: if the data pipeline is more than thirty per cent of the quoted work, it is a separate project. We do not discount AI work to subsidise data engineering.
3. What happens if the model returns garbage five per cent of the time?
Every production model fails sometimes. The product either survives the failure gracefully or it breaks a customer's day. Before we quote, we design the failure path: a reversible action, a human-in-the-loop threshold, a confidence score that triggers a fallback. If the product cannot survive a five per cent garbage rate, we push back. We do not build safety-critical systems with one language-model call.
The discovery artefact
Our discovery engagement produces one document, five to eight pages, always in the same shape.
- Goals. Stated in business terms, not technical terms. One paragraph each, no more.
- Success metric. One number, agreed with the client, that we will measure on day one and on day ninety. No metric, no project.
- Scope: must have for v1. A bulleted list. Short. Specific. No "and more".
- Out of scope. Longer than the must-have list. Items explicitly deferred to a future cycle.
- Data. Sources, shape, access, gaps. Red-flagged if the data pipeline is more than a spike away.
- Integrations. Every third-party API the build touches. Auth model. Rate limits. Pricing tier.
- Failure design. What happens when the model is wrong. Confidence thresholds. Human review points. Rollback mechanism.
- Risk register. Every "I do not know the answer to this yet" we identified. Each one tagged as blocker, amber, or green.
The artefact is the product of discovery. If we can write it, we can quote. If we cannot, we say so and extend discovery by a week. Nobody has ever said no to that.
What we exclude from the fixed quote
Fixed means fixed. But that only works if the boundary is real. We exclude:
- Model version upgrades. A new Claude release with different behaviour is a change request.
- Prompt tuning iterations beyond two rounds post-launch. We tune once at build time, once post-launch. After that, it is ongoing.
- Changes to the input data shape. If the source system changes, we are not on the hook to chase it.
- Third-party API price changes. We quote today's rates. If OpenAI lifts prices mid-project, that is not ours to absorb.
- Scope items that were on the "out of scope" list and later get reclassified as "actually we need this". These become change requests.
Every one of these is spelled out in the statement of work. We have never had a dispute on any of them because they are written down in advance.
The projects we walked away from
Two this year. One was a client who insisted on a model choice that was wrong for the task. One was a client whose data pipeline was not ready and whose timeline did not accommodate fixing it. Both of these would have been losses.
It is always cheaper to walk away during discovery than during the build. Discovery is the contract we most need to respect in our own business.
What we would tell our earlier selves
The scope creep is the spec. Write it down first.
That is the whole insight, really. Everything else in this post is implementation detail. The teams that ship on time are the teams that spent a week deciding what they would not build before they started building.