Fixed price vs time and materials for software projects

Fixed price vs time and materials: how each works

In a fixed price contract, you and the developer agree on a defined scope, a price and usually a set of milestones. The developer carries the risk of the work taking longer than expected. Anything outside the scope becomes a change request with its own price.

In a time and materials contract, you pay an hourly or daily rate for the work actually done, plus any costs such as software licenses. You carry the risk of the work taking longer, and in exchange you can change priorities at any point without renegotiating.

A monthly plan, sometimes called subscription development, sits between the two. You pay a set amount each month for a team that designs, builds, hosts and changes the software, working through an agreed list in priority order. The monthly cost is predictable like fixed price, and the scope can move like time and materials.

Fixed price software development: pros and cons

• Pro: you know the total cost before work starts, which makes budgeting and approvals easier.
• Pro: the scope document forces both sides to think the project through in detail.
• Pro: the developer is motivated to work efficiently, since overruns come out of their margin.
• Con: developers price in risk, so the quote is often higher than the same work billed by the hour.
• Con: every change becomes a negotiation, which slows things down and can sour the relationship.
• Con: if the scope was wrong, you get exactly what was written, not what you needed.
• Con: under pressure, quality and testing are the easiest things for a vendor to cut quietly.

Time and materials: pros and cons

• Pro: you can change direction as you learn, without change orders.
• Pro: you pay for the work done, with no risk premium built into the price.
• Pro: work can start sooner, since you do not need a complete specification first.
• Con: the final cost is uncertain, and open-ended projects can drift.
• Con: you need to review timesheets and progress closely, or have someone who can.
• Con: the developer has less built-in reason to finish quickly.

How to choose a pricing model

1. Judge how clear the scope isIf you can describe every screen and rule today and they will not change, fixed price is realistic.
2. Ask how much you expect to learnNew products and first versions almost always change once real users try them, which favors flexible models.
3. Decide who manages the workTime and materials needs someone on your side watching hours and priorities. If nobody can, prefer a fixed fee.
4. Think past launchIf the software will need regular changes after launch, a monthly plan or retainer usually beats a string of fixed bids.
5. Mix where it helpsA common approach is a fixed-price discovery phase, then time and materials or a monthly plan for the build.

When fixed price is the wrong choice

Fixed price sounds safest, but it often is not for early-stage products, projects with lots of unknowns, or work that depends on third-party systems nobody has tested yet. In those cases the vendor either quotes very high to cover the risk or quotes low and fights every change. If you cannot write down the scope in detail, you are not really buying a fixed price, you are buying an argument later.

Time and materials is the wrong choice when you have a hard budget ceiling and nobody with the time or knowledge to review progress. A monthly plan is the wrong choice for a truly one-off job with a clear end, where a fixed bid is simpler.

What to put in writing whichever you pick

• What is in scope and, just as important, what is out of scope.
• How changes are requested, priced and approved.
• Milestones or review points, and what “done” means for each.
• Rates, billing frequency and any cap or estimate for time and materials work.
• Who owns the code, designs and data, and how you get copies.
• Hosting, support and bug fixing after launch, and what they cost.
• How either side can end the agreement and what happens to the work.