Before scope, before stack, before timeline — you choose an engagement model. It decides who carries the risk when reality diverges from the plan, and it quietly determines your final bill. Most buyers treat it as a billing detail and let the vendor pick; in fact it's one of the few decisions that shapes the entire relationship, because it sets the incentives on both sides. Get it right and the contract works with the project's reality. Get it wrong and you spend the engagement fighting the paperwork instead of building. There are three common models.
Fixed-price
You agree a scope and a price up front. Best when the scope is genuinely well understood — a defined integration, a redesign, a clear MVP with a written spec that isn't going to move.
- ✅ Predictable budget; vendor carries delivery risk.
- ⚠️ Every change is a change-order. Fixed-price work is most exposed to the 27% average overrun when scope shifts — and software scope almost always shifts.
The hidden cost of fixed-price is the risk premium. A vendor pricing a fixed bid has to pad for everything that might go wrong, because they eat the overrun. So you often pay more on average for the comfort of a fixed number — and the model quietly pushes the vendor to interpret scope narrowly, since anything outside the letter of the spec is billable. When requirements are crisp and stable, that's a fair trade. When they're not, fixed-price turns into a slow negotiation over what "done" means.
Time-and-materials
You pay for time spent at an agreed rate. Best when the path isn't fully known — discovery work, evolving products, R&D, or anything where you expect to learn and adjust as you go.
- ✅ Maximum flexibility; you steer continuously and only pay for what you actually decide to build.
- ⚠️ You carry the budget risk, so it demands a trustworthy partner and tight communication.
T&M only works on trust. Because the vendor bills for time, you need real visibility — regular demos, a shared backlog, a burn rate you watch weekly — or the meter runs without accountability. With a good partner that transparency is a feature: you can cut a feature that's proving too expensive the moment you see the cost, rather than discovering it at the end.
Dedicated team / staff augmentation
You retain a team (or specific engineers) for a monthly fee; they work as an extension of yours. Best when you have ongoing work and want continuity and control.
- ✅ Deep product knowledge compounds; you direct priorities sprint to sprint.
- ✅ Avoids the hidden cost and 30%+ replacement risk of in-house hiring while keeping near-employee control.
- ⚠️ Only pays off with a real, continuous backlog — if the work is bursty, you're paying for idle capacity.
A simple way to choose
- Scope is fixed and clear → fixed-price.
- Scope is unknown or evolving → time-and-materials.
- Work is ongoing → dedicated team.
A common mistake
The most expensive error we see is forcing an evolving product into a fixed-price contract because a fixed number feels safer to a finance team. It isn't. You get the worst of both worlds: a price padded for risk, plus a change-order fight every time you learn something. If you genuinely can't specify the work in detail, that's a signal you need T&M, not a tighter fixed bid.
A worked example
A common shape: a company wants to add a recommendations feature but isn't sure what will actually move the metric. Forcing that into fixed-price means specifying a feature nobody can yet specify, so the bid is padded and the change orders start in week two. Run it on T&M instead — a small team, weekly demos, a clear budget cap you watch — and you can try two approaches, kill the weaker one, and only commit fully once you've seen real numbers. Once the feature is proven and the roadmap fills with follow-on work, you roll the same people onto a dedicated-team retainer for continuity. One project, three models, each used where it fits.
What to actually do
Before you sign, answer one question honestly: can I write down, in detail, what "done" looks like? If yes, fixed-price is on the table and you should get competitive bids against that spec. If no, don't paper over the uncertainty with a tighter contract — choose T&M and insist on the transparency that makes it safe (a shared backlog, weekly demos, a visible burn rate). And whatever you start with, make sure the contract allows the model to change without renegotiating the whole relationship.
Many engagements change shape over time — start with one engineer on T&M to prove fit, then scale into a dedicated squad once the backlog is real, and carve out individual fixed-price pieces for well-defined chunks along the way. The contract should flex with you, not trap you, and a partner worth hiring will suggest the shift rather than cling to the bigger model.
Pick the model that puts risk where it's best managed — with whoever controls the scope.
Not sure which fits your situation? Tell us how your work is shaped and we'll recommend a model honestly — even when it's the smaller engagement.
Sources
- Acquaint — Software budget overrun statistics
- Inop — The true cost of a bad hire in 2026