Choosing between fixed price vs time and materials is the single decision that most affects what your software project really costs. Fixed price locks scope and budget before a line of code is written. Time and materials pays for effort as the product evolves. This guide compares both models on cost, risk, speed and control, then shows which one fits your project.
Fixed price vs time and materials: the short answer
If your scope is genuinely stable and you can write it down in detail, fixed price gives you budget certainty and pushes delivery risk onto the vendor. If your scope will change as you learn from users, time and materials gives you the flexibility to change direction without renegotiating the contract every month.
Most projects are not purely one or the other. The practical answer is usually a fixed price discovery phase followed by a time and materials build, or a time and materials engagement with a per-sprint spending cap. We will get to those hybrids below.
What a fixed price contract actually buys you
In a fixed price contract, you and the vendor agree on a defined scope, a delivery date and a total number. The vendor absorbs the cost of any effort beyond the estimate. That is genuinely valuable when you need to defend a budget to a board or an investor.
Where fixed price works best
- MVPs and proofs of concept with a clear feature list and a hard launch date.
- Well-bounded modules such as a payment integration, a migration script, or a reporting dashboard.
- Audits and one-off assessments where the deliverable is a document, not an evolving system.
- Grant or tender funded work where the funder requires a fixed total before approval.
What fixed price quietly costs you
Every fixed price quote contains a risk premium. The vendor cannot see the future either, so they price in a buffer for the unknowns. On a well-specified project that buffer is modest. On a vague one it can be substantial, and you pay it whether or not the risk materialises.
The second cost is friction. Once the scope is signed, every new idea becomes a change order: re-scoped, re-quoted, re-approved. Teams often ship a feature they already know is wrong simply because changing it is administratively expensive. That is a poor trade when you are still learning what users want.
What time and materials actually buys you
In a time and materials contract you pay an agreed rate for the hours or sprints the team actually works. Scope is managed through a prioritised backlog rather than an appendix to a contract. You can reorder, add or drop work at the start of each sprint.
Where time and materials works best
- Products with a real roadmap that will keep evolving after launch.
- Discovery-heavy work where requirements depend on user feedback or data you do not have yet.
- Team extension, where you want engineers embedded in your own process. See our guide to the offshore development center model.
- Legacy modernisation, where nobody can honestly scope the surprises hiding in old code.
What time and materials quietly costs you
The obvious risk is an open-ended bill. Without discipline, a time and materials engagement can drift for months with impressive velocity and unimpressive outcomes. The budget is only as controlled as your backlog.
The less obvious cost is that management effort shifts to you. Someone on your side has to prioritise, accept work and say no. If you do not have a product owner with the time and authority to do that, time and materials will underperform regardless of how strong the engineering team is.
Fixed price vs time and materials: side by side
| Dimension | Fixed price | Time and materials |
|---|---|---|
| Scope definition | Locked before kickoff | Refined every sprint |
| Budget control | Fixed total, quoted upfront | Rolling, best managed with a cap |
| Change requests | Formal change order and re-quote | Absorbed into the backlog |
| Delivery risk | Mostly the vendor | Shared, weighted to the client |
| Speed to start | Slower, needs a full specification | Faster, starts from a backlog |
| Transparency | Low visibility into effort | High, effort is reported |
| Client effort | Front-loaded into specification | Continuous product ownership |
| Best fit | MVP, PoC, bounded modules | Product teams, ODC, long roadmaps |
Why the cheaper model is rarely the cheaper outcome
Both models fail for the same underlying reason: the project was larger and less understood than anyone admitted at signing. Research from The Standish Group, whose CHAOS studies have tracked software project outcomes for decades, has consistently found that only around a third of projects finish fully successfully, while roughly half are challenged by delays, overruns or missing features.
The same research points to a pattern worth acting on. Small projects succeed far more often than large ones, and iterative delivery outperforms big up-front planning. That is an argument for cutting work into smaller pieces, whichever contract model you sign.
Scale makes it worse. Analysis published in Harvard Business Review by Bent Flyvbjerg and Alexander Budzier found that a meaningful minority of large IT projects become genuine outliers, with cost overruns severe enough to threaten the business that commissioned them.
The practical lesson is not “choose fixed price to be safe”. It is that a fixed total on a badly understood scope buys you a false sense of safety, and the correction arrives later as change orders, quality shortcuts or a rebuild.
The middle ground most buyers should consider
Two hybrids solve most of the tension between the models, and both are common in mature outsourcing relationships.
Fixed price discovery, then time and materials build. You buy a short, fixed price discovery phase that produces a technical design, a prioritised backlog and a credible estimate. You then start the build with real information. If you decide not to continue, you still own a usable specification.
Capped time and materials. You work sprint by sprint, but the contract sets a ceiling per sprint or per quarter. You keep the flexibility of a backlog and the vendor cannot exceed an agreed number without your written approval. In practice this is what most of our long-running clients use.
If you are still deciding whether to build custom software at all, our build vs buy guide is the better starting point, because the contract model only matters once building is the right answer.
Seven questions to ask before you sign
- Is the scope stable enough to quote a fixed total? If the honest answer is no, a fixed price is a guess with a signature on it.
- Who owns the source code and IP the day the contract ends? This should be unambiguous and in writing, not implied.
- What exactly triggers a change order, and what does it cost? Ask for the process and the rate before you need them.
- Which named engineers are on the team, and can they be swapped? A rate card means little if the people behind it rotate.
- How is acceptance defined? A demo, a test coverage threshold and a written sign-off are three very different bars.
- What is the exit path? Notice period, handover, documentation and credentials should be agreed at the start.
- Is the rate all-in? Confirm whether project management, QA, DevOps and meetings are included or billed separately.
How Tinasoft structures fixed price vs time and materials
Tinasoft Vietnam has delivered more than 300 projects for around 100 clients since 2018, across web, mobile, ERP, CRM and IoT. That volume has taught us where each model breaks, and we would rather say so before a contract than after.
We quote fixed price when the scope is genuinely fixed. That typically means an MVP with an agreed feature list, delivered in four to six weeks, or a bounded module with clear acceptance criteria. Our MVP development guide explains how we keep that scope small enough to be quotable.
For anything with a living roadmap we recommend capped time and materials, usually inside a dedicated team or ODC structure. You get named engineers, a per-sprint ceiling and full visibility into where the hours went. Every engagement is covered by an NDA, and IP ownership transfers to the client.
We publish our rates rather than making you ask. You can see current ranges by role and seniority on our Vietnam software outsourcing rates page, along with a quote form we answer within 24 hours.
Frequently asked questions
Is fixed price always more expensive than time and materials?
Not always, but usually per unit of work, because the vendor prices in a risk buffer. On a tightly specified project that premium is small. On a vague one it is large, and you pay it even if the risk never materialises.
Can I switch from fixed price to time and materials mid-project?
Yes, and it is common. The usual trigger is a discovery phase or MVP delivered at a fixed price, after which the relationship moves to sprints. Agree the switch conditions and the rate card at the start so the transition is not a renegotiation.
How do I stop a time and materials contract from running away?
Set a per-sprint or quarterly cap, require written approval to exceed it, and review a prioritised backlog every sprint. Ask for effort reporting by task. If a vendor resists any of those three, that is the answer to your question.
Which model is better for a startup MVP?
Fixed price, if you can freeze the feature list. The budget certainty matters more than flexibility at that stage, and a short, bounded MVP is exactly the kind of project fixed price handles well.
Does the contract model affect who owns the code?
It should not. IP ownership is a separate clause and should transfer to you in either model. If a vendor ties code ownership to the pricing model, treat that as a serious red flag.
Choosing with your eyes open
There is no universally better answer to fixed price vs time and materials. There is only a better fit for how stable your scope really is, how much product ownership you can supply, and how much budget certainty you need to defend.
Be honest about the first of those three and the other two usually resolve themselves. If you would like a second opinion on which model suits your project, we are happy to give one before you commit to anything.
