The contract decides who carries the risk
Two software projects with the same team and the same goal can feel completely different depending on the contract. One model puts the risk of overruns on the vendor. The other puts it on you. Neither is better. They suit different situations.
How fixed price works
You agree on a defined scope and a price for delivering it. If the work takes longer than planned, the vendor absorbs it.
What you get: a known cost, a clear deliverable and an easy approval inside your business.
What it costs you: flexibility. Because the vendor carries the risk, the scope has to be pinned down in detail before work starts, and every change goes through a formal process. Vendors also price in a margin for the unknowns.
Government contracting rules describe fixed price as best suited to work where the requirements are well defined. That holds for software too.
How time and materials works
You pay for the hours worked at agreed rates. The scope can move as you learn.
What you get: flexibility. You can change priorities week to week, and you pay only for work that is done.
What it costs you: certainty. The final cost depends on how the project goes, so you need to watch progress closely. The same contracting rules note that this model needs active oversight from the buyer, because it gives the vendor less incentive to control cost.
Start here:
- Ask how well you can describe the finished product today.
- If you can write the requirements on a page and they will not change, lean toward fixed.
- If you expect to learn as you go, lean toward flexible.
Where each one goes wrong
Fixed price fails when the scope was not really known. The team builds exactly what was written, you realize it is not quite what you need, and every correction becomes a negotiation.
Time and materials fails when nobody is watching. Without regular demos and a clear priority list, hours accumulate and the finish line keeps moving.
The options in between
Most real projects use a blend.
Fixed scope by phase. Break the work into stages and fix each one once it is understood. Discovery and design first, then the first release, then the next.
Monthly retainer. A set team for a set monthly fee, with priorities reviewed regularly. This suits a product that is live and evolving.
Capped time and materials. Hourly billing with a ceiling, so you keep flexibility and have a limit.
This is how we work: a fixed scope when the plan is clear, or a monthly retainer when priorities will evolve. On fixed-scope work, a change produces a written change order before anyone starts on it.
How to choose
- You know exactly what you want and it will not change. Fixed scope.
- You are building something new and expect to learn. Flexible, with a cap or short phases.
- The product is live and you are improving it. Retainer.
- You are not sure. Start with a short fixed discovery phase, then decide with real information.
Protect yourself either way
The contract type matters less than these four habits.
- Milestones you can see. Tie payments to working software, not to documents.
- Regular demos. Every week or two, so surprises are small.
- A written change process. Cost and date impact agreed before the work.
- Ownership from day one. Code, cloud accounts and design files in your name.
The short version
Fixed price buys certainty and costs flexibility. Time and materials buys flexibility and costs certainty. Match the model to how well you know what you are building, and split the work into phases when you are unsure.
Next step: if you are comparing proposals written on different models, send us the outline. We can help you put them on the same footing, whether or not you work with us.