The hidden cost of a fixed-price project

We're wary of fixed estimates for software, especially for anything new. Tie a project to a single number up front and you make change expensive, exactly when the freedom to change course is the point.

Change is the normal case

On real projects the requirements shift as everyone learns. Under a fixed scope, every change has to be re-estimated and pushed to a later phase, so delivery becomes a few big milestones months apart instead of a steady flow of working software.

Frequent delivery beats a big reveal

Shipping in small increments means feedback lands early, while it's still cheap to act on, and the work stays visibly on track. A fixed estimate pulls the other way: hold everything back, reconcile at the end, and hope it still fits.

What an honest estimate looks like

We still estimate, we just refuse to pretend. An honest estimate is a range with its assumptions written down: what we think is simple, what we suspect is hairy, and which unknowns will move the number. As the project teaches us more, the range narrows in the open, instead of a fixed number quietly absorbing the risk as hidden padding.

Priced as we go

A fixed price gives a feeling of budget control, but it caps the project and usually costs more in the end, because the risk has to be priced in. We'd rather quote as we go, keep you in charge of what gets built next, and value responding to change over following a plan.