Fixed Price vs Time and Materials: Which Software Development Contract Is Right for You?

Ask three software companies how they price work and you may get three different answers: a fixed quote, an hourly rate and "a monthly retainer for a dedicated team". They sound similar until the project hits its first surprise. Then the model you chose decides who carries the risk, how fast decisions are made and whether the relationship stays healthy.

This guide explains the main models in plain terms, shows when each one fits and lists the contract clauses that protect you whichever you choose. It draws on more than eight years of leading product delivery and on how we structure work at Creuto.

The three common models

Fixed price

You agree a total price for a defined scope. The company carries the risk of delay and underestimation, so they usually add a buffer. It works well when requirements are written, screens are designed and the scope is unlikely to change much.

• Strengths: predictable budget, clear deliverables, less day-to-day management for you.
• Weaknesses: changes can be slow and costly, and a vague scope turns into disputes. Companies may cut corners to protect margin if the estimate was tight.

Time and materials (T&M)

You pay for the hours or days worked at agreed rates. Scope can flex as you learn. It suits exploration and projects where the problem is not yet understood.

• Strengths: flexibility, quick adaptation to what you discover, you pay only for work done.
• Weaknesses: no ceiling unless you set one, and it needs active supervision. A slow team earns more, so incentives can drift.

Dedicated team or retainer

You pay a monthly fee for a team that works on your roadmap. It suits ongoing product development after the first release, when there is always more to build and you want continuity.

• Strengths: continuity, deep product knowledge, steady pace.
• Weaknesses: a fixed monthly cost whether the work is busy or quiet, and it needs a clear roadmap to be worth it.

Side-by-side comparison

When each model fits

Choose fixed scope when

• You have a written PRD and designed screens.
• You must report a budget to investors, a board or a finance team.
• The project has a clear finish, such as a first release or a defined integration.

Choose time and materials when

• You are exploring a problem and do not yet know what to build.
• The work is research-heavy or depends on results you cannot predict.
• You can review progress weekly and will set a monthly cap.

Choose a retainer when

• You have launched and have a steady backlog of improvements.
• You want the same team to keep learning your product.

The hybrid most founders should use: milestones

Pure fixed price struggles with change. Pure T&M struggles with budget. A milestone approach combines the strengths of both:

1. Write the plan first. A PRD and a clickable prototype define what you are buying. See how to write a PRD.
2. Split the work into milestones. Each has a written scope and a deliverable you can test on a staging version.
3. Tie payments to milestones. You pay when you have verified the deliverable against agreed acceptance criteria.
4. Review between milestones. You can adjust the next one using what you learned, through a simple change process.

This is how we work at Creuto: fixed milestones tied to agreed deliverables, so you never face surprise hourly billing, and you can steer between stages. For a rough sense of budget before you talk to anyone, try the free app cost calculator and read the project costs guide.

A worked example of milestones

To see how the hybrid works, imagine a booking platform for a service business. The plan might be split like this:

After each one you test, give feedback and approve. If you learn something important after milestone two, you adjust the scope of milestone three through the change process, with the cost and time effect agreed in writing before work starts.

How to review a fixed-price proposal

• Is every feature written down, with exclusions listed?
• Are milestones described by what you can test, not by dates alone?
• Does it say who will do the work?
• Is the change process spelled out, including how estimates are produced?
• Are warranty and post-launch support defined?
• Does the proposal reference a PRD or design you have reviewed?

A proposal that scores badly on these points is not necessarily dishonest. It may simply be unfinished. Ask the company to fill the gaps before you compare prices.

Contract clauses that protect you with any model

• Ownership: you own the source code, design files and infrastructure from the start, held in accounts you control.
• Acceptance criteria: each milestone lists how you will decide it is done, in testable terms.
• Change process: new requests are documented, estimated and approved in writing before work begins.
• Warranty: a defined period after launch when bugs are fixed without a new charge.
• Confidentiality: a mutual NDA covering your idea, data and customers.
• Team and subcontracting: who does the work, and whether any of it is outsourced.
• Exit terms: how either side can end the agreement and the handover that follows, including repositories, documents and credentials.
• Payment schedule: amounts tied to deliverables, not only to dates.

Have a lawyer review the final contract. Our checklist in how to choose a software development company shows how to compare proposals before you reach that stage.

Red flags in pricing proposals

• A fixed price quoted before anyone asked about your users or goals.
• An hourly rate with no estimate, no cap and no review rhythm.
• "Unlimited changes" at a fixed price. Someone will pay for them later.
• Final payment due before you have tested the working product.
• Code ownership that transfers only at the very end, or not at all.

How to decide in 10 minutes

1. Is your scope written and designed? If yes, lean to fixed milestones.
2. Are you still learning what the product should be? If yes, start with a short, capped T&M discovery, then move to fixed milestones.
3. Do you need a firm budget for investors or a board? If yes, insist on milestones with written scope.
4. Can you supervise the team closely every week? If not, avoid open-ended T&M.

If you want a second opinion on a proposal you have already received, bring it to a call. I will point out what is vague, what is missing and what I would ask the company to change.