Where Budgets Die: The Gap Between a Definition and a Plan

Every software build starts with the same question, and it arrives before anything exists to answer it. "Roughly how much would this cost to build?" The founder asks it on the first call — reasonably, because the whole decision hangs on it. The agency answers it on the second — quickly, because the deal hangs on it. A number gets written into a proposal, the proposal gets signed, and two months later everyone discovers what that number was actually made of.

This post is about what an early build estimate is actually made of — and why the honest version of that number can only exist after a phase most founders have never been offered.

The two ways an estimate gets made

There are exactly two methods for pricing a build, and they produce numbers that look identical on a proposal and behave completely differently in month four.

Top-down. Someone takes your idea, compares it to things they've built before, adjusts for how the conversation felt, and lands on a figure — often calibrated, consciously or not, to what your budget can bear. It takes two calls and a slide deck, which is precisely the problem: at that point the product exists only as a conversation, and conversation is a famously lossy format. There is nothing to add up yet, so the number isn't a sum of anything. It's a bet.

Bottom-up. Someone designs the product first — the architecture, the data model, the user journeys — then breaks the scope into units small enough to price individually, prices each one, and adds them up. It's slow, because the design has to exist before the math can. But the resulting number is a sum of decisions already made, not a wager on decisions nobody has made yet.

Neither number announces which kind it is. Both arrive formatted to the cent.

What the early number actually hides

Here's the part that feels cynical but is just arithmetic. When an agency quotes a fixed price for a product that's still fog, the ambiguity doesn't disappear — it gets converted into money, in one of two directions:

• Pad it. The agency prices in every unknown as risk, and the quote comes back thirty to fifty percent heavier than the build needs to be. You overpay for fog.
• Lowball it. The agency quotes lean to win the signature, knowing every unresolved decision will surface later as a change request — billed to you, at a moment when switching costs make you a captive buyer. You pay for the fog anyway, plus interest, plus the argument.

Both are rational responses to being asked to price the unpriceable. Neither is a conspiracy. But notice what they have in common: the founder pays for the ambiguity either way — the only question is whether it's priced honestly up front or extracted later under pressure. This is the mechanism underneath the stalled builds we've written about: the guess runs out, and velocity is the first thing quietly sacrificed to protect the margin.

The error bars matter more than the number. At idea stage, an estimate can honestly be off by a factor of four in either direction — not because anyone is incompetent, but because the unknowns genuinely dominate. After a written definition, the range tightens. After real design work, it tightens again, to something you can actually sign. Estimators call this the cone of uncertainty, and it's the least-argued-with idea in software: precision isn't a diligence problem you can hustle your way past. It's an information problem. The only way to narrow the cone is to do the work that replaces unknowns with decisions.

What planning actually buys

So what work narrows the cone? Not ceremony, and not a thicker proposal. A Planning Sprint produces a specific set of artifacts, and each one converts a category of unknown into a decision:

• Architecture and stack decisions — how the system is structured and what it's built on, with the reasoning written down. This kills the "we'll figure out the hard part later" unknown, which is where the worst estimate blowups live.
• A data model — the entities and relationships the product stands on. These are the decisions that are cheap to make now and brutal to unmake after six sprints of code are standing on them.
• User journeys and key flows — the shared picture of what the software actually does, specific enough that "done" is checkable instead of debatable.
• Scope broken into estimable units — the product decomposed into pieces small enough to price and demo individually. This is the step that turns estimating from judgment into arithmetic.
• A Statement of Work — scope, price, and timeline in a document you can sign, precisely because the design work behind the numbers is done rather than promised.

Notice the order. The estimate isn't an input to this process or a sales artifact that precedes it. The estimate is the exhaust. It's what falls out the bottom once the unknowns have been converted into decisions — which is why any number produced before that conversion is borrowing precision it hasn't earned.

The test of a real estimate

You don't have to take any of this on faith. A real estimate has properties you can check from the founder's side of the table, without reading a line of code:

• It's attached to a document you own. The plan behind the number should be written to be executable by any competent team — the same portability test that separates real discovery from a sales motion. A price that only makes sense inside one agency's head is leverage for them, not information for you.
• It lists its assumptions and exclusions explicitly. Every estimate rests on assumptions. The honest ones say what they are; the fragile ones hope you don't ask.
• The scope breaks into units small enough to demo weekly. If the price decomposes into pieces you could watch get built one by one, the estimate was built the same way. If it's three line items and a total, it wasn't.
• It survives the question "what would make this number wrong?" Ask it directly. A bottom-up estimate has a specific answer — these assumptions, these exclusions, these units. A top-down one has a confident pause.

"But I just need a ballpark"

Fair — and a ballpark is a legitimate tool, as long as everyone treats it as one. A band that's honestly labeled indicative, wide enough to contain the truth, and used to make a go/no-go decision is doing its job. The sin isn't imprecision; it's precision theater — a number formatted to look engineered when it's actually atmospheric.

This is why our own front doors end in bands, not quotes. A Discovery Sprint closes with an indicative investment range — explicitly framed as firming up after planning, never as a teaser number. The band's job is to tell you whether the build is in your budget's neighborhood. The plan's job is to tell you what it costs. Confusing those two jobs is how budgets die.

Where this fits

None of this is a standalone ritual — it's one rung of a delivery ladder where each stage makes the next stage's commitments honest. Discovery (for ideas) or a Build Audit (for existing code) settles what and whether. Planning designs how — and it's only here, on top of a design, that a price becomes a fact instead of a bet. The Build then delivers against that Statement of Work in weekly slices, with the working demo every week that keeps "done" honest. Care keeps it healthy after launch.

The pattern to notice: every trustworthy number in that sequence is produced after the work that justifies it, and every expensive surprise in software comes from someone demanding the number first. Estimate risk isn't managed during a build. It's engineered out before one.

The short version

You cannot buy an honest estimate for a product nobody has designed. A number quoted after two sales calls isn't a price — it's a bet wearing a suit, and you'll pay for its ambiguity either as padding up front or as change requests later. The only way out is the boring one: a short planning phase that converts unknowns into decisions, decisions into estimable units, and units into a sum you can actually sign.

Two to four weeks of design is what separates "we think" from "we'll commit." If you're holding a build quote right now and can't tell which kind it is, that's what our Planning Sprint is for — or take the two-minute product readiness assessment and find out which front door you're actually standing in front of.