Every client who arrives after a bad experience with a previous vendor tells a version of the same story: the estimate looked reasonable, the first month went fine, and then somewhere around sprint four the plan quietly doubled. By the time anyone admits it, the budget is gone and the deadline has been rewritten twice.
The uncomfortable truth is that most estimates do not fail because engineers are bad at guessing. They fail because the original number was never an estimate at all — it was a sales figure with a delivery story attached to it.
Three ways scope hides
1. Decisions that were never made
An estimate that says “integrate with the payment provider” hides ten decisions: which provider, which flows, who owns refunds, how disputes surface in the back office, what happens when the webhook arrives twice. If those questions are open, the number is fiction. We write them down as an assumptions register, and each assumption gets a price.
2. Work that is 80% done
Integration work, migrations and performance problems all share the same trap: the last 20% is where the unknowns live. We split everything into vertical slices that reach production — a thin path through the whole system — instead of horizontal layers that only look finished in a demo.
3. Quality deferred to the end
If testing, security review and accessibility are phases at the end of the timeline, they are not phases. They are a second project. Ours are gates inside every sprint: automated tests, review, dependency scanning and a load baseline from the first slice onwards.
What we do before quoting a number
- Two weeks of discovery. We interview the people who will use the system, read the existing code or data model, and map the integrations nobody has documented.
- A written assumptions register. Every assumption is listed, priced and owned by someone on your side or ours. You can challenge any of them before signing.
- Risk buffer as a line item. Not hidden inside padding — a separate, visible number you can see burn down sprint by sprint.
- A named pod. The estimate is produced by the tech lead who will do the work. No hand-off from a pre-sales architect to a delivery team that has never read the proposal.
The weekly habit that keeps it honest
Every Friday, clients receive a written update: what shipped, what slipped, why, and what it changes about the projection. Bad news travels first. It is a two-minute read, and it is the single mechanism that has kept our estimates within range across long engagements.
When scope genuinely has to change — and sometimes it does — you get three options with prices attached: reduce scope, move the date, or add budget. You choose. That is the entire conversation.
Five questions to ask any vendor
- Who wrote the estimate, and will they be on my project?
- What assumptions does it rest on, and what happens if one is wrong?
- What is the risk buffer, and how do I see it burn down?
- What does “done” mean per slice — deployed, tested, documented?
- Show me an engagement that went over, and tell me how you handled it.
If a partner cannot answer the last one, they have not been honest with a client yet — or they have never noticed.