Fixed-price and time-and-materials contracts differ above all in who carries the risk of the unknown. With fixed price, the vendor carries it, prices it into the quote and protects itself with change requests. With time and materials, you carry it in exchange for flexibility. Fixed price suits small, well-defined work; most startup products do better with a capped hybrid.
Neither model is a trick, and neither is automatically safe. Each one rewards different behavior from the vendor, and once you see those incentives, the choice gets much easier.
How does a fixed-price software contract work?
The vendor agrees to deliver a defined scope for a set price. The scope is written up as a specification, often with designs attached, and payments are split across milestones such as design sign-off, beta and launch.
Anything outside the specification is a change. Changes go through a change request: the vendor estimates the extra work, you approve the cost, and the timeline moves. Many fixed-price contracts also include an acceptance period, when you test each milestone against the specification, and a warranty period after launch when defects are fixed at no extra charge.
The appeal is obvious. You know the number before you start, which makes budgeting and investor conversations simpler.
How does time and materials work?
You pay for the time actually spent, at agreed hourly or daily rates for each role, usually invoiced monthly or per sprint. The vendor gives you an estimate, but it is a forecast, not a promise. Scope can change whenever you like: you reorder the backlog, and the team works on whatever matters most next.
The appeal here is flexibility. You can change direction after user feedback without renegotiating anything, and with a sound contract you can stop at any point and keep what has been built. The price of that flexibility is that nobody knows the final bill in advance.
Fixed price vs time and materials side by side
| Factor | Fixed price | Time and materials |
|---|---|---|
| Who carries the risk | Mostly the vendor, priced into the quote | Mostly you |
| Budget certainty | High, until changes start | Low, unless capped |
| Changing scope | Slow: every change is a change request | Easy: reprioritize every sprint |
| Needed up front | A detailed specification | A clear goal and a backlog |
| Vendor's incentive | Deliver the spec in as few hours as possible | Keep the engagement going |
| Hidden cost | Risk buffer and change requests | Drift and slow progress |
| Your effort | Heavy at the start and at acceptance | Steady, every week |
| Best for | Small, stable, well-understood work | Products that evolve with feedback |
Both columns have a weak spot. Fixed price protects your budget and exposes your quality and flexibility. Time and materials protects your flexibility and exposes your budget. The real question is which risk you are better placed to manage.
The incentives nobody mentions on the sales call
What fixed price quietly rewards
A vendor quoting a fixed price is betting it can deliver for less than it charges. Sensible vendors protect that bet in three ways:
- A risk buffer. If the team's honest estimate for a hypothetical project is 400 hours, the quote might be built on 500 or 600. You pay for that buffer whether or not the risks happen.
- A narrow reading of the spec. Ambiguous lines get the cheapest reasonable interpretation. “Users can reset their password” may arrive without the branded email, the rate limiting or the edge cases you assumed.
- Priced changes. Once you are committed, every change is quoted by a vendor who knows you are unlikely to walk away mid-build.
The bigger danger comes when the vendor underestimates. Every extra hour comes out of its margin, and the pressure to cut corners grows by the week. Tests, documentation, security hardening and error handling are invisible in a demo, so they tend to go first. You end up with software that passes acceptance and then struggles in production.
What time and materials quietly rewards
A vendor paid by the hour has no direct financial reason to be efficient. Most good teams are efficient anyway, because they want to keep the client and the reference, but nothing in the contract pushes for it. Without oversight, two things tend to happen:
- Scope drift. Ideas get added, nothing gets cut, and the estimate grows quietly month after month.
- Invisible slowness. If nobody on your side can tell whether a feature should take three days or three weeks, you will pay for three weeks.
So time and materials only works when someone on your side can read progress: a technical co-founder, an experienced product lead, or a part-time CTO. Without that person, it is close to a blank check. Misaligned incentives like these are among the classic reasons outsourced software projects fail.
When fixed price is the right call
Fixed price works when the scope is small, stable and understood the same way by both sides. Good candidates include:
- A marketing website with approved designs
- A well-defined integration, such as connecting your system to a payment provider or accounting tool
- Rebuilding an existing app whose behavior is already known
- A discovery or audit phase with a fixed list of outputs
- A single feature with finished designs and written acceptance criteria
It also helps when the vendor has built nearly the same thing before, so the quote rests on experience rather than hope. If you cannot describe what “done” looks like in a page or two, the work is not ready for a fixed price. Learning how to scope an MVP tightly is the way to get there.
When time and materials is the better fit
Time and materials suits work where learning what to build is part of the job:
- A new product or MVP, where plans will change once real users try it
- Ongoing development after launch, where priorities shift every few weeks
- AI features and other uncertain work, where nobody knows how well an approach performs until it is tried
- Rescues and takeovers, where the team cannot know what is broken until it looks
The condition is always weekly visibility: working software shown every week or two, a backlog you can see and reorder, and a report of hours spent against the estimate. These are the same habits that help you manage developers without a technical background. With them in place, time and materials is often the more honest model for product work, because you pay for the work itself instead of paying someone to absorb uncertainty.
Hybrid models that split the risk fairly
The best contracts I see borrow from both models. These are the setups I recommend most often:
- Fixed-price discovery, then time and materials. Pay a fixed fee for discovery first (one to four weeks is common) and have it deliver a scope, wireframes or designs, an architecture and an estimate. Then build on time and materials against that estimate. You find out whether you work well together before committing to the big number.
- Capped time and materials. You pay for actual time up to an agreed ceiling per phase or per month. Check what happens at the cap: does the vendor stop and ask, or keep going at its own cost? A cap that can be raised by email is not much of a cap.
- Milestone-based fixed price. Instead of one fixed price for the whole product, agree on a fixed price per phase, and quote the next phase only when the current one is delivered. Each quote is smaller and better informed.
- Fixed budget, flexible scope. You fix the money and the time, for example six two-week sprints, and prioritize scope inside that box. The most valuable features get built first; the least valuable get cut if time runs out.
Rule of thumb: fix the price of anything you can fully describe today, and cap the budget of anything you will only understand once you start building it.
How to protect yourself under either contract
The safeguards around the contract matter more than its type. Whichever model you pick, ask for these:
- Your company owns the code repository from day one, and all work lands there as it happens
- A demo of working software every week or two, not slide updates
- Written acceptance criteria for each feature before work starts
- A written estimate and your approval before any change is built
- A rate card for each role, so extra work is priced predictably
- Payments tied to delivered, working software rather than calendar dates
- A monthly report of hours used against the estimate (time and materials)
- A defect warranty period after launch (fixed price)
- The right to end the contract on short notice, with a duty to hand over code, documentation and access
- A written IP assignment covering everything built for you
The last two are the ones founders skip and later regret; the guide to who owns the code you pay for covers ownership terms in detail. Rules differ from country to country and none of this is legal advice, so get a qualified lawyer to read the contract before you commit.
So which should you choose?
Choose fixed price for work you can describe completely today, such as a website, an integration or a discovery phase. Choose time and materials, capped and reported weekly, for products you will keep shaping after launch, and only if someone on your side can judge progress. For a first product built by an agency, the setup I usually recommend is a fixed-price discovery followed by capped build phases, with the team judged by what it ships each week.
When you compare quotes, look past the headline number. A low fixed price attached to a vague specification often ends up the most expensive option once the change requests arrive. A realistic picture of what it costs to build an app helps you tell an ambitious quote from an impossible one.
Frequently asked questions
Is fixed price cheaper than time and materials?
For the same work, often not. A fixed-price quote includes the vendor's own estimate plus a buffer for the risk it is taking on, so you pay for uncertainty whether or not it materializes. Time and materials can come in lower if the project runs smoothly, or higher if the scope wanders. Compare the total you expect to pay, including likely change requests, rather than the headline number.
Can you switch from fixed price to time and materials mid-project?
Yes, if both sides agree, and it is often the right move when the original scope no longer matches what you need. Close out the fixed-price work first: agree on what has been delivered, what has been paid for and what happens to work in progress. Then sign a new arrangement with clear rates, a budget cap and a reporting rhythm, so the change does not turn into an open checkbook.
What is a dedicated team model?
A dedicated team model means you pay a monthly fee for a set group of people who work only on your product, usually through an agency or outsourcing firm. It behaves like time and materials, since you pay for capacity rather than a defined outcome, but the stable team builds up knowledge of your product over time. It works well for ongoing development once someone on your side sets priorities and reviews the work.
Is a monthly retainer the same as time and materials?
They are close relatives. Time and materials bills the hours actually worked, so the invoice changes every month. A retainer reserves an agreed amount of time or scope for a fixed monthly fee, which makes budgeting easier and usually guarantees availability. Many fractional CTO engagements, including mine, run on a monthly retainer scoped to the work needed, adjusted up or down as the company changes.