“Fixed price or time and materials?” is one of the first contract questions to settle in a software project, and it is easy to treat one model as simply safer. Neither is. Each one moves risk to a different side of the table, and each one goes wrong in its own way. This guide shows who carries what, how changes are priced, the hybrid models worth knowing, and the same app followed through both models.
What is the difference between fixed price and time and materials?
In a fixed-price project you agree one price for a defined scope before the work starts; in a time and materials project you pay for the time the team actually spends, at agreed rates, and the scope can change as you go.
- Fixed price buys an outcome. The team estimates the work, adds a margin for the risk of being wrong, and commits to delivering the written scope for that price. Anything outside the scope is a change.
- Time and materials (T&M for short) buys capacity. You pay for hours or days worked, invoiced at an agreed interval such as every two weeks or every month, plus any third-party costs such as hosting or licences. You decide what the team works on next.
- A monthly team is a form of time and materials: a set team for a set monthly fee, working through your priorities. It suits products with no end date.
The choice matters less than people think at the start and more than they expect by the end, because it decides what happens on the day the plan changes, and in software you should plan for that day.
Who carries the risk in each model?
In a fixed-price project the delivery team carries the risk that the estimate is wrong; in time and materials you carry it. That is the whole trade. The table below follows it through the questions buyers ask.
Is a fixed price padded?
Yes, and it should be: a fixed price includes a margin for the risk the team takes on, because some estimates will be wrong and the team pays for those. The useful question is not whether there is a margin, but whether you can see what it covers.
Three ways to judge a fixed quote:
- Ask for the estimate behind it, broken down by feature or milestone. A team that can’t show its working is pricing by feel.
- Ask which assumptions it rests on. “Payments through one gateway”, “content supplied by you”, “two rounds of design changes”. Each one is a place where a change request can come from later.
- Compare it with a time and materials estimate for the same scope, if the team offers both. The gap is roughly what you are paying to hand over the risk.
A quote far below the others is the one to worry about. Either the scope was read differently, or the team plans to recover the difference through change requests.
How should change requests work?
A change request should be written down, estimated and approved before any work on it starts, so you always know what a change costs before you commit to it. In a fixed-price project, change requests are how the scope moves; in time and materials there is no formal request, but the same discipline keeps the bill honest.
Watch the small changes as closely as the big ones: a run of small asks (“can the button also…”, “while you’re in there…”) that nobody writes down moves the plan just as far. Keep a change log from the first week, even on time and materials, and read it at every review, so you can see how far the plan has moved and decide while there is still time to act.
Not sure which fits?
Tell us what you’re building and how settled the scope is, and we’ll talk through which model fits it.
What are the hybrid options?
The hybrid options are a paid discovery followed by a fixed build, time and materials with a cap, fixed-price milestones, and a monthly team. Each one lets you put every phase of the project in the model that fits it.
When the scope isn’t clear yet, start with the first hybrid. In a 2–3 week Discovery Sprint we run workshops and user research, plan the system, prioritise features, prototype key screens and write a build estimate. It costs ₹1.5–3 lakh.
What does a normal payment schedule look like?
Pay for a fixed-price project as a deposit, then payments tied to milestones you can check, with the last payment due at launch; time and materials is invoiced for the time worked, every two weeks or every month. What matters more than the exact split is what each payment is tied to.
- Tie milestones to things you can see: designs approved, a feature working on a test build, the app live on the stores. A milestone defined only by a date pays for time, not progress.
- Be wary of a large deposit with nothing to check until the end. If most of the money is paid before you’ve seen working software, you are carrying the risk the fixed price was meant to remove.
- On time and materials, ask for the hours behind every invoice, by person and by task, and a running total against the budget or cap.
For reference, our own terms are still being finalised: fixed-price work is typically paid 40% to start, 50% across build milestones and 10% at launch, agreed per project. The current draft prices and plans are on our pricing page.
The same app under both models
The clearest way to see the difference is to follow one project through both models and watch what happens on the days the plan changes. The example below is illustrative: one booking app, the same four surprises, and two ways of handling them.
Neither model “won”. Fixed price protected the client from the integration overrun, which was the team’s estimating risk. Time and materials made the change of direction cheaper and faster, because nobody had to reprice a scope that was already out of date. In both columns, the project went well because every change was written down and decided on its cost.
How do you decide?
Decide by asking how settled your scope is and how much time you can give the project each week; the checklist below turns those into six yes-or-no tests. Tick the ones that are true for your project. The more you tick, the better a fixed price fits.
If you land in the middle, start with the part you’re sure of. If the uncertain part is what to build, a short discovery settles it. If the uncertainty is ongoing, because the product will keep changing after launch, a monthly team fits better than a series of fixed projects, and our hiring page explains how that works. The way a project is run matters as much as the contract: see how we run a project step by step, and, for the delivery side of the same decision, our guide to agile or waterfall.