In this guide
- How do the three models compare?
- When does fixed price work best?
- When is time and materials the better choice?
- When does a dedicated team make sense?
- Can you combine the models?
- What should every software contract include, whatever the model?
- What are the warning signs in a proposal?
- Frequently asked questions
- Choosing the right model for your project
Pick fixed price when the scope is clear and you need budget certainty. Pick time and materials when the product will evolve and you can manage priorities closely. Pick a dedicated team when you have a long-running backlog and want people focused on your product month after month. Many projects mix models, such as fixed-price phases after discovery.
The model you choose decides who carries the risk when things change, and things always change. Here is how each one works in practice.
How do the three models compare?
The core difference is who absorbs uncertainty: the supplier under fixed price, you under time and materials, and both, in a steady monthly arrangement, with a dedicated team. Everything else follows from that.
| Factor | Fixed price | Time and materials (T&M) | Dedicated team |
|---|---|---|---|
| How you pay | Agreed price for an agreed scope, usually in milestones | Hours or days actually worked | A monthly fee for named people |
| Budget certainty | High | Low to medium | High per month, open-ended overall |
| Flexibility to change | Through change requests | High; reprioritise any time | High within the team's capacity |
| Who carries scope risk | Mostly the supplier | Mostly you | Shared; you direct the work |
| Upfront effort | Detailed scope needed | Can start with less detail | Onboarding and a backlog needed |
| Your management time | Lower | Higher | Highest; you set priorities |
| Best for | Well-defined projects, MVPs after discovery | Evolving products, R&D, unclear scope | Ongoing products with steady work |
| Main risk | Rigidity; disputes over what was "in scope" | Budget drift | Paying for idle capacity |
When does fixed price work best?
Fixed price works best when you can describe what you want in enough detail that two suppliers would quote the same thing. It gives you a number to plan around and makes the supplier responsible for estimating well.
It suits:
- A first version (MVP) or internal tool after a proper discovery phase.
- Projects with a hard budget ceiling, such as grant-funded or board-approved work.
- Owners who want predictability more than week-to-week flexibility.
How to make it work:
- Start with discovery. A fixed price on a vague brief is either padded or doomed. Our explainer on the software discovery phase shows how scope gets nailed down.
- Write clear requirements and acceptance criteria. Our requirements document template is a good starting point.
- Agree a change-request process before work begins: how changes are estimated, approved and paid for.
- Tie payments to milestones you can see working, not to dates alone.
Fixed price is only as fair as the scope document behind it. If the scope is thin, both sides end up arguing over what was included.
GRWW quotes fixed prices after a discovery call because most of the growing businesses we work with want to know the total before committing.
When is time and materials the better choice?
Time and materials is better when you genuinely cannot define the scope yet, or when you expect to change direction based on what you learn. You pay for effort, so you keep full control of priorities.
It suits:
- Early product experiments where the next feature depends on user feedback.
- Technical unknowns, like a new AI feature or an unfamiliar integration, where a fixed estimate would be a guess.
- Ongoing improvements to an existing system, where tasks are small and varied.
How to keep it under control:
- Set a monthly or sprint budget cap and review spend against it every week or two.
- Prioritise ruthlessly. Keep a ranked backlog so the most valuable work happens first.
- Ask for timesheets with real detail, linked to tasks, not just totals.
- Insist on working demos at the end of each sprint, so you see progress rather than hours.
The risk is drift: small additions that each seem reasonable and together double the budget. T&M rewards owners who stay closely involved.
When does a dedicated team make sense?
A dedicated team makes sense when your software is core to the business and there is enough steady work to keep a team busy for many months. You get people who know your product deeply, without hiring them directly.
It suits:
- SaaS products with a continuous roadmap.
- Businesses replacing several systems over a year or more.
- Companies that want an extension of their in-house team, managed day to day by their own product owner.
What to watch:
- You need a product owner. Someone on your side must set priorities and make decisions, or the team will drift.
- Idle capacity costs money. If the backlog runs dry, you still pay the monthly fee.
- Check the notice period and how team members are replaced if someone leaves.
- Agree how quality is measured, for example release frequency, bug rates and demo quality, rather than hours logged.
Can you combine the models?
Yes, and combining them is often the safest route. Each phase of a project carries a different amount of uncertainty, so it is reasonable to use a different model for each.
Common combinations:
- Fixed-price discovery, then fixed-price build. The discovery output becomes the scope for a firm build quote.
- Fixed-price MVP, then T&M improvements. Certainty for the first release, flexibility once real users start asking for things.
- Fixed-price MVP, then a dedicated team. Once the product proves itself and the roadmap is long, move to a steady team.
- T&M proof of concept, then fixed price. Test a risky technical idea for a short, capped period, then fix the price once the approach is proven.
Timelines matter here too. Typical ranges are 8–16 weeks for an MVP and 4–9 months for a mid-size platform; see our guide to realistic custom software timelines for how those break down.
What should every software contract include, whatever the model?
Regardless of pricing model, the contract should protect your ownership, your data and your ability to walk away. These clauses matter more than the hourly rate.
| Clause | What to look for |
|---|---|
| Intellectual property | Code, designs and documentation assigned to you on payment |
| Source code access | Code in a repository you own throughout, not handed over at the end |
| Hosting and accounts | Cloud, domain and third-party accounts in your business's name |
| Acceptance | How deliverables are tested and signed off, and how long you have to review |
| Change requests | How changes are estimated, approved and priced |
| Payment terms | Milestones or monthly billing tied to visible progress |
| Warranty | A period after launch when defects are fixed at no cost |
| Confidentiality and data | How your data and customer data are handled, including privacy-law obligations |
| Termination and handover | Notice period, final payments and a documented handover if you part ways |
Get a lawyer to review any significant contract. A developer's job is to build well; a lawyer's is to make sure the agreement protects you.
What are the warning signs in a proposal?
Be wary of any proposal that is vague about scope, ownership or how changes are handled. These gaps tend to become disputes later.
- A fixed price with no written scope or assumptions.
- T&M with no budget cap, reporting or demo schedule.
- A dedicated team offer with no named people or replacement policy.
- Silence on who owns the code, or ownership only after an extra fee.
- Large upfront payments not tied to deliverables.
- No mention of testing, warranty or maintenance.
Contract model is one of several big decisions; our custom software development guide walks through the others, including cost and process.
Frequently asked questions
Is fixed price always more expensive than time and materials?
A fixed price includes the supplier's allowance for risk, so the same work can cost slightly more than an ideal T&M project. In practice T&M projects often grow beyond their first estimate, so fixed price frequently ends up cheaper for well-defined work. The quality of the scope decides which way it goes.
What happens if I need changes on a fixed-price project?
You raise a change request. The supplier estimates the time and cost, and you decide whether to add it now, swap it for something of similar size or leave it for a later phase. That process should be written into the contract.
How do I stop a time and materials project running over budget?
Set a cap per sprint or month, keep a prioritised backlog and review progress and spend every week or two. Ask for working demos rather than reports alone. If spend climbs faster than visible progress, pause and re-plan.
Is a dedicated team the same as hiring in-house?
Not quite. You direct the work, but the supplier employs the team, handles their benefits and replaces people if they leave. It is more flexible than hiring and usually faster to start, but you still need someone internally to set priorities.
Which model is best for a first-time software buyer?
For most first projects, a fixed-price discovery followed by a fixed-price build is the safest option. You get budget certainty, a clear scope and a defined finish line, then you can choose a more flexible model for later improvements.
Choosing the right model for your project
If you are weighing proposals that use different contract models, we are happy to talk through which fits your situation. Share your brief or the proposals you have, and we will explain the trade-offs and send a fixed-price quote of our own after a discovery call. You can also see the kinds of projects we take on via our services page.