A new client called us last week. They had hired a different shop for a six-month, $180,000 fixed-bid build. Month nine, they were $90,000 over and the product still couldn't ship. They wanted us to "just finish it."
We've heard this story enough times that it has a shape. The shop sold a fixed bid because the client demanded one. The shop padded the estimate by 30% to feel safe. Three months in, the requirements were already different from the contract. The shop refused to change scope without a new contract. The client refused to sign a new contract because "we already paid for this." Nobody trusted anyone. Everyone lost.
Why fixed-bid keeps failing
Fixed-bid pricing pretends that custom software is like pouring concrete. You measure the slab, you quote the slab, you pour the slab. The problem is that software requirements aren't a slab. They are a guess, made early, that gets less wrong as you build.
A fixed-bid contract locks in the guess. Every divergence between the guess and reality becomes a contract dispute instead of a design conversation. Here are the four predictable failure modes:
- Padding wars. The shop pads its estimate to absorb unknowns. The client negotiates the padding down. The padding that should have absorbed real risk is now gone, and the first surprise eats into margin.
- Scope litigation. Every email becomes potential evidence. The shop tracks scope changes obsessively. The client feels nickel-and-dimed. Engineers stop talking to users because every conversation might create a "change order."
- Death-march endgame. Three weeks before the deadline, the shop realizes they're behind. They throw bodies at the project. Quality drops. The client gets a buggy product on time and an unmaintainable codebase forever.
- Shipping the contract instead of the product. The shop builds what the contract says, even when the contract is wrong. The client gets the wrong product on budget. Both sides claim victory while the actual business problem is unsolved.
What works instead
We've tried three alternatives across about 80 client engagements. Here's how they perform.
Time and materials with a budget cap
Bill weekly. Show the client where the time went. Set a cap that triggers a stop-work conversation, not a contract amendment. The cap is "tell me before you spend more," not "you can never spend more."
This works for clients who trust their vendor and want flexibility. It does not work when the client treats every invoice as an opportunity to renegotiate. About 40% of our work is structured this way.
Capped-scope sprints
Two-week sprints with a fixed scope per sprint and a fixed price per sprint. At the end of each sprint, the client can stop, change direction, or continue. The shop commits to the sprint scope, not the project.
This is our default for new clients. It gives the client predictability (they know what each sprint costs) and us flexibility (we are not locked into a six-month guess). About 50% of our work uses this model.
Fixed-bid (yes, sometimes)
Fixed-bid still works when three conditions are met:
- The work is well-defined and small. "Migrate this WordPress site to a static generator" is fixed-bid-able. "Build us a portal" is not.
- The shop has done it many times. The first project is never fixed-bid. The tenth one might be.
- Change requests have a published price list. Not "we'll quote you," but "this kind of change costs $X."
About 10% of our work is fixed-bid, and it's almost always a redo of something we've done before.
How to tell which model your project needs
Ask three questions, honestly:
Can you describe the product to me in writing such that two independent teams would build the same thing?
If no, you do not have a fixed-bid project. You have a discovery project, possibly followed by a build project.
If the first version is wrong, do you want to be able to change direction?
If yes, capped-scope sprints will save you money over fixed-bid. The flexibility is worth the loss of price certainty.
Are you willing to read a weekly progress report and respond to questions within two business days?
If no, time-and-materials will hurt you, because you cannot course-correct fast enough.
A final note on padding
We see vendors quote 6-month projects and deliver in 9. We have done this ourselves. The honest answer is that nobody can predict a 6-month software project with the precision of a fixed bid. The dishonest answer is to pretend they can.
If you are getting a fixed-bid quote for a complex project, ask the vendor what their average overrun has been on the last 10 fixed-bid projects. The good ones will tell you. The honest answer is usually between 20 and 40 percent.
That overrun is not a defect of the vendor. It's a defect of the contract structure.
Want our process doc on capped-scope sprints? Ask for the playbook and we'll send it over with no obligation.