How a software project is priced shapes how it goes. More than the team, more than the tech stack. We've worked under all three common models — fixed bid, time and materials, and outcome-based — and they each break in predictable ways.
Fixed bid
Best for: scope you can write down precisely. A new marketing site. A specific integration. A migration with a known endpoint.
Risks:
- Vendors who win on price will protect margin by limiting scope — expect every change request to feel adversarial.
- Vendors who win on capability will pad the bid heavily. You'll pay 20-40% more than T&M would have cost.
Use when: the spec is genuinely stable and the buyer cares more about predictability than absolute cost.
Time and materials (T&M)
Best for: ongoing product development. Anything where requirements will evolve as you learn from real usage.
Risks:
- Without strong product ownership on the client side, T&M projects drift. Months pass. Velocity is hard to feel.
- Vendor incentives don't punish slow work — opposite, in fact.
Use when: there's a competent product owner on your side, and you trust the vendor enough to expose your roadmap to them.
Outcome-based
Best for: narrowly-defined business outcomes — "increase conversion by X%," "reduce support volume by Y%."
Risks:
- Almost impossible to write a clean SOW. Both sides will spend more time on contract language than on the work.
- Vendor cherry-picks the easy wins, ignores hard structural problems.
- Attribution disputes when other factors move the metric.
Use when: the outcome is genuinely measurable, isolatable, and the vendor has a real track record of moving that specific metric.
What we actually do
For most engagements: fixed bid for discovery (2-3 weeks), then T&M for delivery, with monthly burn-down updates and a clean off-ramp at each month. That structure protects the client from runaway spend without forcing the vendor to pad an estimate against unknowns.
The pricing model isn't the project plan — but pick it wrong and the project plan won't save you.
