Fixed-price vs dedicated team: how to actually choose

We quote both models, and we have watched both fail. The failures are not random — they follow a pattern, and the pattern is not about budget size. It is about how much of the specification can genuinely be frozen before work starts, and whether the client has a person who can make a decision inside 24 hours.

Here is the honest version of the trade-off, written by a vendor, which you should read with appropriate suspicion.

What a fixed price actually is

A fixed price is a risk transfer with a premium attached. You are asking the vendor to absorb the uncertainty of an estimate. They will price that uncertainty, and if they are honest, they will price it correctly: our fixed bids carry a 20–35% contingency over the same scope quoted on time and materials. On genuinely novel work, more.

So the first thing to be clear about: a fixed-price project is not cheaper. If everything goes perfectly, you have overpaid by roughly a third for insurance you did not need. That may still be the right trade — insurance often is — but understand what you bought.

What it genuinely buys you:

• A cap. If it takes twice as long, that is the vendor's problem. This is real and it is worth money.
• A number you can take to a board, a bank or a parent company.
• Less demand on your time. You are buying an outcome, not managing a team.

What it costs you, beyond the premium:

• Change-request friction. Every change becomes a commercial negotiation. Six weeks in, you learn something that makes the original plan wrong — and now doing the right thing requires a contract amendment, a quote and a week of emails. Some clients simply stop suggesting improvements, and the product is worse for it.
• A misaligned incentive on quality. Once the price is locked, the vendor's margin improves with every hour not spent. The pressure on tests, on refactoring, on the edge case nobody will notice this quarter, is structural. Good vendors resist it. It is still there.
• Specification lawyering. Both sides re-reading a document written by people who did not yet understand the problem, arguing about whether "user management" implied roles.

What a dedicated team actually is

You buy capacity — say four engineers, a designer and a QA, at a monthly rate — and you direct it.

What it buys you:

• Adaptability at zero commercial cost. Priorities change on Monday; the team works on the new thing on Monday. No amendment, no quote.
• Better engineering, in our experience, because there is no incentive to skip the test.
• Institutional knowledge that compounds. Month six is markedly more productive than month one.

What it costs you:

• You now carry the risk. If it takes twice as long, you pay twice.
• It requires a product owner with real authority. This is the failure mode, and it is by far the most common way a dedicated-team engagement burns money. If the team is blocked on a decision for three days, you paid for three days of nothing. We have had an engagement where the client's PO could not approve a schema change without a committee that met fortnightly, and the burn rate did not pause for the committee.
• No cap. Requires trust and requires you to actually look at the burn-up chart.

The five questions

Answer these honestly and the model chooses itself.

1. Can you write the acceptance criteria today?

Not the feature list — the acceptance criteria. "The user can reset their password" is a feature. "A reset link is emailed within 30 seconds, expires in 15 minutes, is single-use, and rate-limits to 3 attempts per hour per account" is an acceptance criterion. If you cannot write these for 80% of the scope, a fixed price is a fiction. You will get exactly what the ambiguous document said, and you will not like it.

2. Does the scope depend on third parties you do not control?

ONDC. A bank's API. An insurer's underwriting system. A government portal. A legacy ERP whose documentation is a retired employee.

Never fixed-price this. We do not, and if a vendor offers to, they have either priced in an enormous premium or they have not read the integration docs. Integration risk is unbounded and it is not the vendor's to absorb: nobody can estimate a system they cannot see, whose sandbox does not behave like production, and whose support desk takes eleven days to reply.

3. Is discovery done — properly?

If the answer involves "we will figure that out during the build", you are describing time and materials whether or not the contract says so. You are just choosing whether the friction shows up as change requests or as invoices.

4. Do you have a decision-maker who can answer within a day?

One person. Named. With authority to make a call that they will not later have overturned by someone who was on holiday.

If yes → a dedicated team will be efficient. If no → a fixed price will at least contain the damage from your slow decisions, because the vendor has committed to an outcome and will chase you for the answer.

This is genuinely counter-intuitive: slow decision-making is an argument for fixed price, not against it. It is the one situation where transferring risk is unambiguously worth the premium.

5. Is this a v1 to learn from, or a rebuild of something you already run?

A rebuild — where the requirements are demonstrably encoded in a system you use daily — is the ideal fixed-price project. You can specify it, because it exists.

A v1 in a market you are still probing is the worst possible fixed-price project. The whole point of a v1 is that you will change your mind, and you have just made changing your mind expensive.

What we actually recommend most of the time

A hybrid, because most projects are not one thing:

1. Fixed-price discovery. Three to six weeks, small, capped. Output: clickable prototype, technical architecture, a real backlog with estimates, and integration spikes that have actually called the third-party API. This de-risks everything that follows. Both parties can walk away here, cheaply, and we have — twice, and both times it saved everyone a fortune.
2. Fixed-price the known core. After discovery, the parts that are genuinely well-understood — auth, the admin, the CRUD, the standard checkout — can be bid with confidence. This is often 50–60% of the scope.
3. Capacity for the rest. The integrations, the AI feature, the thing you are not sure users want: a dedicated team, with a sprint cadence and a burn-up chart you look at every fortnight.
4. A pre-approved change budget. 10–15% of the fixed portion, agreed upfront, drawn down without a new contract. This single clause removes most of the change-request friction that makes fixed-price projects miserable, at a cost you have already budgeted.

Numbers, so this is not just opinion

Across our fixed-bid projects over roughly six months in duration, change requests have averaged 18–40% of the original contract value. That is not a sign of a bad estimate. It is what happens when a client sees working software and learns something. Budget for it — the projects that go badly are the ones where the client budgeted zero and then had to choose between the right product and the approved number.

Contract clauses that actually matter

Regardless of model:

• Acceptance criteria, written, per milestone. Without these, "done" is an opinion.
• A definition of "defect" versus "change". Agree it before you need it. This is the single most common source of vendor-client conflict.
• IP transfers on payment, milestone by milestone — not at the end. If the relationship ends in month four, you should own months one to four.
• Source in your repository from day one. Not delivered at the end. Not on the vendor's GitHub.
• A written exit and handover plan. What you get, in what state, within how many days. Read it before you sign, not when you are angry.
• Rate card locked for the term, with a defined ramp-up/ramp-down notice (30 days is fair both ways).

Red flags, in both directions

Watch the vendor if: they fixed-price an integration-heavy scope without a spike; they quote in under 48 hours on a complex brief; they will not name the actual people; the contract has no exit clause; the price is 40% below everyone else, which means either they have misunderstood the scope or they intend to make it back on change requests.

Watch yourself if: you cannot name your product owner; your acceptance criteria are a feature list; you want a fixed price for something you cannot describe; you are choosing on headline price. The cheapest quote in this industry is, with depressing reliability, the most expensive project.