Fixed Price, Time and Materials or Milestones: How to Structure a Software Development Contract

Key Takeaways

• Fixed price fixes the cost and the scope. It works when the scope is small and well understood; otherwise the supplier prices in the risk, and every change becomes a negotiation.
• Time and materials bills the time actually spent. It handles change well but needs visibility and trust, and a budget ceiling to protect you.
• Milestone-based contracts sit in between: the work is split into stages, each with a defined result, acceptance criteria and payment. For most custom applications it is the best balance.
• A short, paid discovery phase before the main contract makes any model more reliable, because the estimate is built on facts instead of assumptions.
• Whatever the model, insist on written acceptance criteria, a change-request process, IP assignment and a handover clause.

A software development contract model decides two things: how the price is set and who carries the risk when the work turns out to be bigger or different than planned. In custom software it nearly always does, because the details of a product only become clear as it is built. There are three common models: fixed price, time and materials, and milestone-based contracts that combine the two. Here is how each one works, when to use it, and what to put in the contract whichever you choose.

The three models at a glance

Fixed price: predictable on paper

A fixed-price contract sets one amount for an agreed scope. It is attractive because the budget seems certain, and it suits small, well-defined jobs: a feature with clear specifications, a migration with a known starting point, an audit.

For larger products, the certainty is often an illusion. An estimate made before the work starts is the least reliable one you will ever get; estimation research describes this as the cone of uncertainty, where early estimates can be off by a wide margin in either direction and only narrow as the project progresses. A supplier who commits to a fixed price on that basis protects itself in one of three ways:

• by adding a risk premium to the price, which you pay even if nothing goes wrong;
• by defining the scope as narrowly as possible, so that anything not written down becomes a paid change request;
• or, under pressure, by cutting what you can't see: tests, documentation, security.

None of this is bad faith. It is the logical result of the model. Martin Fowler notes that a fixed price can work for evolving software if it is the scope, not the budget or date, that stays flexible: you fix the budget and agree together which features fit inside it.

Time and materials: flexible, if you can see the work

Under time and materials (régie in French), you pay for the time actually worked, at an agreed daily or hourly rate. It is the most honest reflection of how software is built, and it handles change easily: when priorities move, the team simply works on something else. It is also the model closest to the Agile Manifesto's preference for "customer collaboration over contract negotiation".

The risk moves to you. Time and materials works well when you can see what you are paying for:

• regular demos of working software, not status reports;
• access to the repository and the task tracker, so progress is visible between demos;
• a budget ceiling per month or per phase, with an agreement to stop and discuss before it is exceeded;
• a team you trust, which is why it is the usual model for ongoing work and long-term partnerships.

Milestones: the practical middle ground

A milestone-based contract splits the project into stages. Each stage has a defined result, written acceptance criteria and an amount, paid when the criteria are met. A typical structure for a custom application looks like this:

1. Discovery and architecture, priced as a fixed amount: users, workflows, integrations, data model, risks and a delivery plan. You own the result and can take it to any team.
2. A first usable release, scoped from what discovery found.
3. Further releases, each planned and priced once the previous one is in use.

This keeps the commitment proportional to what is known. The supplier estimates a stage it understands, rather than a whole product it has only heard described, and you are never more than one stage away from being able to stop, change direction or change team. It is close to how public-sector digital services are run, with a discovery phase before committing to build.

Clauses to include in any model

The contract model matters less than what the contract says. Whichever you choose, check for these clauses.

• Acceptance criteria. What "done" means for each deliverable, in writing, and how long you have to test before accepting.
• Change requests. Any work outside the agreed scope is quoted in writing, with its effect on cost and timing, before it starts.
• Payment schedule. Payments tied to delivered results, not to dates on a calendar or to a large upfront deposit.
• IP ownership. A written assignment of rights to you, from creation. Our guide on who owns the code explains why paying is not enough under French law.
• Accounts and access. Repositories and hosting in your accounts from the first day.
• Warranty. How long the supplier fixes defects in delivered work at no extra cost.
• Termination and handover. What happens if either side ends the contract: notice, what is delivered, and the assistance owed to a new team. Our handover checklist lists what a complete handover includes.
• Data protection. A data processing agreement under GDPR Article 28 if the supplier will handle personal data.

How to choose

• Small, fully specified job? Fixed price.
• New product, or scope you can't describe in detail yet? Start with a paid discovery, then milestones.
• Ongoing improvements and maintenance, with a team you know? Time and materials, with a monthly ceiling.
• Inherited or struggling application? A short fixed-price assessment first, then milestones once the risks are known. Our guide on rescue or rewrite explains why.

For what drives the total budget itself, see how much a custom web application costs.

Frequently asked questions

Isn't fixed price always safer for the client? Only when the scope is genuinely fixed. For a product that will evolve, you pay a risk premium up front and still face change requests later, so the final cost is often higher than an honest time-based estimate.

What is a reasonable budget ceiling under time and materials? One you can afford to spend before re-planning: often a month of the team's time, or the estimate for the current phase. The point is to force a conversation before the money is spent, not after.

Can we change model during a project? Yes. Moving from a fixed-price discovery to milestones, then to time and materials for maintenance, is common and sensible: the model follows how much is known.

Who writes the acceptance criteria? Both sides, before the work starts. The supplier proposes them from the specification; you check that they describe what your users actually need.

---

At FNB Solutions, we work by milestone, with written acceptance criteria for each one, and an optional paid discovery phase whose written plan you own. Out-of-scope requests are quoted in writing before work starts. Our full contract terms are public. To discuss your project, start a conversation.

Sources

• Fixed Price, Martin Fowler
• Cone of Uncertainty, Wikipedia
• How the discovery phase works, GOV.UK Service Manual
• Manifesto for Agile Software Development
• GDPR Article 28: processor