Fixed price or time and materials: choosing the model that fits the work
The contract model decides who carries the uncertainty, and uncertainty is the main thing a software project is made of. Choosing it well is worth more than negotiating the rate.
By Georgiy Gres · Founder & CEO August 2026 8 min read Both models work. Both are used by serious firms on serious projects. What differs is where they put the risk, what behaviour they reward on each side of the table, and which kinds of work they suit. Matching the model to the work is one of the highest-leverage decisions a buyer makes, and it is made before anyone writes a line of code.
Below is how each model behaves once the work is under way, which situations suit it, and the hybrid that most experienced buyers arrive at after a few engagements.
Fixed price
You agree a scope, a price and a date. The vendor carries the risk of the estimate being wrong.
It suits work whose shape is genuinely known before it starts: a defined integration, a redesign of an existing set of screens, a migration between two documented systems, an audit, a mobile app whose backend already exists and is stable.
What it rewards. Because the vendor carries the estimate risk, they price for it — a typical fixed bid carries a contingency of 20 to 40 per cent over the internal expectation. If the work goes smoothly you have paid that contingency; if it goes badly the vendor absorbs it. Over many projects the arithmetic evens out, and on any single project it is a coin toss you have paid a premium to avoid.
What to watch. The scope document becomes the arbiter of every conversation, which means clarity in it is worth a great deal. Requests that fall outside it become change requests, and the speed and fairness of that process determines whether the engagement stays pleasant. Agree the mechanism in the contract: who assesses a change, in what turnaround, and at what rate.
You can describe the finished thing precisely enough that two engineers reading your description would build the same system.
Time and materials
You pay for the time spent at an agreed rate. You carry the risk, and you keep the ability to change direction at any point.
It suits product development, anything touching a system nobody has fully examined yet, work where user feedback will change the plan, and long-running engagements — which is to say, most software.
What it rewards. Honesty about progress, because there is no incentive to defend an estimate. Direction can change in a week rather than a change-request cycle. The vendor has no reason to argue that a request was out of scope, which removes a whole category of friction.
What to watch. You need visibility, and you should insist on it: a demo every sprint, a written report against a plan, and a burn rate you can see. Ask for a cap per month or per phase — a good vendor will offer one before you ask.
The destination is clear and the route will be discovered. Which is the normal condition of building a product.
The dedicated team
A monthly fee for a named team of a defined size, working on whatever your roadmap says that month. It is time and materials with the administration removed and the continuity guaranteed.
It suits a live product with a standing roadmap. The team learns your domain once and keeps the knowledge, which is where the compounding advantage lives. Several of our clients have worked with the same engineers for more than seven years; the delivery speed in year three is not comparable to year one, and no procurement exercise can buy that.
What to watch. Agree what happens when your roadmap goes quiet for a month, and agree notice on both sides. Both are ordinary requests and both should be in the agreement.
Side by side
| Fixed price | Time & materials | Dedicated team | |
|---|---|---|---|
| Who carries estimate risk | Vendor | Client | Client |
| Premium paid for certainty | 20–40% | None | None |
| Cost of changing direction | A change request | A conversation | A conversation |
| Budget predictability | Exact | Capped per phase | Exact per month |
| Time to start | Slowest — scope must be complete | Fast | Fast |
| Best for | Known, bounded work | Product development | A live product with a roadmap |
The hybrid most people arrive at
After a couple of engagements, most buyers converge on the same three-part structure. It is what we propose by default, because it puts each phase on the model that actually fits it.
- A fixed-price discovery. Two to four weeks, a firm number, producing a system design, a delivery plan and a costed backlog. You own all three whatever happens next, and they are the assets that make every later estimate accurate.
- A fixed-price first release, priced from that design. The uncertainty has been removed by the discovery, so the contingency is small and the fixed price is fair to both sides.
- A dedicated team from launch onward, monthly, working the roadmap. This is the phase where scope is genuinely open-ended, so the model that handles change gracefully is the right one.
The structure has a useful property beyond the economics: each stage is a natural decision point. You can stop after discovery with a plan in hand, or after the first release with a working product, and neither exit leaves you holding something unfinished.
Terms worth agreeing in any model
- Repository ownership from day one. The code lives in your organisation, not the vendor’s, from the first commit.
- Infrastructure in your accounts. Cloud resources under your billing, with the vendor granted access. Straightforward at the start, awkward to unwind later.
- A named change mechanism. Who assesses, how fast, at what rate.
- A defined demo cadence. Something running that you can open, on a fixed day, whatever the model.
- Handover terms written at the beginning. Documentation standard, a support window, and the shape of a transition. Agreeing this while everyone is optimistic is much easier than agreeing it later.
How we usually structure it
Our own fixed-price work sits where fixed price belongs: audits, consultations and defined pieces with a published number and a published turnaround, listed on the services pages. Build engagements start with a paid discovery and move to a monthly team, because that is the model that matches how a roadmap actually behaves. Either way the architecture is written and signed off before development starts, which is what makes any of these numbers meaningful.
Not sure which model fits your project?
Describe the work in thirty minutes and we will tell you which structure suits it — including when that means a fixed price from someone else. You keep the recommendation either way.
Questions people ask about this
Is fixed price safer for the client?
It is more predictable, which is not the same thing. You transfer estimate risk to the vendor and pay a contingency of roughly 20 to 40 per cent for it, and you accept that changes go through a change-request process. For genuinely well-defined work that is a good trade. For product development it usually costs more and moves slower.
How do I keep time and materials under control?
A cap per month or per phase, a working demo every sprint, a written report against the plan, and visibility of the burn rate. A vendor comfortable with all four is one you can run this model with.
What is a fair contingency inside a fixed bid?
Twenty to forty per cent over the vendor’s internal expectation, depending on how much of the work touches systems they have not examined. A bid with no contingency is a bid that will become a change-request conversation.
Can a project start fixed price and move to a team?
That is the structure we recommend: a fixed-price discovery, a fixed-price first release priced from it, then a monthly team for the roadmap. Each stage is also a clean stopping point.
Who should own the repository and the cloud accounts?
You should, from the first commit and the first resource. It costs nothing to set up at the start, it is awkward to unwind later, and it is the clearest signal of how a vendor thinks about your independence.
