The three common models
Software work is usually sold in one of three ways. Fixed price agrees a scope, a date and a total cost up front. Time and materials bills for the hours actually worked, usually against a budget estimate. A dedicated team gives you a group of engineers, designers and testers who work only on your product for a recurring fee.
None is universally best. The right choice depends mainly on how well you understand what you are building and how long you expect to keep building it.
Fixed price: certainty, if the scope is stable
A fixed price gives a predictable budget. The vendor carries the risk of underestimating, which is attractive when money is tight. It works best when requirements are clear and unlikely to change: a well-specified integration, a marketing site or a rebuild with a known feature set.
The weaknesses are structural. To protect themselves, vendors add contingency to the price. Because the scope is fixed, every change becomes a negotiation, and both sides are incentivised to argue about what was included. If you learn something halfway through, as you almost always do, you either pay for a change request or ship something that no longer fits.
- Good for: clearly defined, short projects with a firm budget.
- Be careful with: products where user feedback will shape features.
- Insist on: a written scope, acceptance criteria and a clear change process.
Time and materials: flexibility with discipline
You pay for the work done, so scope can change freely and you only fund what you decide to build. This suits products still being discovered, such as a first version of a startup product, where the most valuable features are not yet known.
The trade-off is that cost is not capped by default. You need transparency to manage it: regular reports of hours against plan, a prioritised backlog and the ability to stop at any sprint boundary. Without this attention, budgets drift. A common safeguard is a monthly budget ceiling that requires explicit approval to exceed.
Dedicated team: continuity for long-running products
A dedicated team becomes part of your organisation's rhythm. People learn your domain and codebase, so knowledge accumulates instead of being re-explained to a new group each project. This suits products with a continuing roadmap, where you would otherwise hire and manage engineers directly.
The cost is a recurring commitment whether or not there is enough work, so it is poor value for short or sporadic projects. It also needs a product owner on your side who can prioritise; a team without direction is an expensive way to stand still. Check how team changes are handled, and who is responsible if someone leaves.
How to decide
Ask these questions in order:
- How well defined is the scope? If you can write acceptance criteria today, fixed price becomes viable. If not, prefer time and materials or a team.
- How long will the work run? Weeks suggest fixed price or time and materials; many months or open-ended suggest a dedicated team.
- How likely is change? The more you expect to learn, the more you need flexibility.
- How much management capacity do you have? Flexible models need an engaged product owner.
- What is the cost of being wrong? If a budget overrun is unacceptable, either fix the scope tightly or phase the work.
Hybrids often work best
You do not have to pick one for the whole life of a product. A common pattern is a fixed-price discovery phase that produces a specification, prototype and estimate, followed by time-and-materials delivery of the first release, and then a smaller dedicated team to maintain and extend it. Each phase uses the model that matches how much is known at that point.
Another approach is a fixed price per sprint or per milestone, which keeps budgets predictable while allowing the scope of later milestones to adapt.
Questions to put to any vendor
- What assumptions does this price depend on?
- How are changes requested, estimated and approved?
- How will I see progress and spending each week?
- Who owns the code at every stage, and when does it transfer?
- What happens if we need to stop early?
Whichever model you choose, insist on working software at regular intervals. Frequent small releases make problems visible early, and they give you a cheap exit if the relationship is not working.