How I scope a fixed-price build.

Every project I take starts with the same promise: a fixed price, in writing, before work starts. That promise is only as good as the scoping behind it. If the scope is vague, a fixed price is either padded against the unknown — you overpay — or optimistic, and the relationship sours the first time reality disagrees with the estimate. So the scoping phase carries the whole thing, and it costs you nothing: discovery is free, and it takes about a week.

§1The call comes first

Twenty minutes. You describe the problem in your own words — usually it sounds like “we run this process across three tools and a spreadsheet, and it breaks every month.” I ask what the software must do, not what it should look like: who touches it, how often, what happens when it fails today, and what you’re paying for the tools it would replace.

Two outcomes are possible, and I tell you which one on the call. Either custom software beats your current setup on the 5-year math, or it doesn’t. If it doesn’t — the spend is under $300/month, or the process still changes shape every few weeks — I say so and point you at an off-the-shelf tool. Rent if you need it this week. Build when the process is stable.

§2The scope document

If we go ahead, I write the scope. It’s a plain document, not a proposal deck, and every line is checkable at delivery:

• What the software does, feature by feature, in the language of your business — “staff check in a delivery by scanning the label,” not “barcode integration module”
• What it explicitly does not do — the line that prevents the quiet drift every fixed price dies of
• Acceptance criteria per feature: the sentence we both read at handover to agree it’s done
• The milestone plan — what ships when, and what you pay at each step

4.2  Low-stock alerts
     — When any item drops below its reorder threshold,
       the system emails the manager within 15 minutes.
     — The threshold is editable per item, per location.
     DONE MEANS: a test item crossing its threshold
     produces the email, with the right item and location.

That “done means” line is the whole trick. A fixed price without acceptance criteria is an argument scheduled for week six. With them, done is a checkbox, not a negotiation.

§3Where the risk sits

Once you approve the scope, the number is fixed. If the work takes longer than I estimated — and sometimes it does — that’s my cost, not yours. I price that risk in the honest way: a buffer I always add and rarely need, not a padded line item pretending to be a feature.

Scope changes mid-build don’t break this. New ideas show up once you see a working demo — that’s normal, and the demos come every two weeks precisely so they show up early. Each one becomes a written add-on with its own small fixed price, which you approve or park. The original number never quietly grows.

§4What a milestone plan looks like

An illustrative split for a mid-band build — the shape is canonical, the numbers scale with the project:

You never pay for work you haven’t seen. And because the repository sits in your account from day one, walking away at any milestone leaves you owning everything you’ve paid for — which is exactly the pressure on me that keeps the milestones honest.