Fixed price vs time-and-materials: which contract fits your web project?

Choose fixed price when you can describe the finished project completely before work starts; choose time-and-materials when you can't. A fixed price buys you budget certainty, but only for the scope written in the quote, and anything outside it becomes a change request. Time-and-materials buys you flexibility to change direction, but you carry the risk on the total cost, so it only works with visible progress and a cap you control. For a complex system you can't yet describe, the safest route is usually a short, paid discovery phase first, followed by a fixed price for what it uncovers.

Neither model is "better". Each moves risk to a different side of the table. Once you see where the risk sits, the right choice for your project is usually obvious.

What the two models actually are

• Fixed price means you and your developer agree on a defined result (these pages, these features, this integration) for one agreed sum. If the work takes longer than estimated, that's the developer's problem.
• Time-and-materials (often shortened to "T&M") means you pay for the hours or days actually worked, at an agreed rate, usually invoiced weekly or monthly. If the work takes longer, you pay for the extra time.

An everyday analogy: fixed price is ordering from a set menu. You know the price before you sit down, but swapping the main course costs extra. T&M is hiring a private chef by the evening. You can change the menu halfway through dinner, but the bill depends on how long the chef stays in the kitchen.

Why the choice costs (or saves) you money

The contract model decides who pays when reality differs from the plan. And on software projects, reality almost always differs from the plan somewhere.

Risks on a fixed-price project

For you, the buyer:

• You pay for uncertainty up front. A sensible developer adds a buffer to cover what they can't foresee. If the project turns out simple, you've still paid for the buffer.
• Anything not written down isn't included. "I assumed the blog was part of it" is the most common, and most expensive, conversation in fixed-price work.
• Pressure can land on quality. If the estimate was too tight, a developer losing money has an incentive to cut corners you won't see until later, such as testing, documentation or performance.

For the developer:

• They carry the overrun. A badly underestimated project can mean weeks of unpaid work, which is exactly why vague scopes get padded quotes.

Risks on a time-and-materials project

For you, the buyer:

• The total cost is open. Without a cap and regular check-ins, a project can drift well past what you had in mind.
• You need to stay involved. T&M rewards buyers who review progress every week and make decisions quickly. If you disappear for a month, hours still accumulate.

For the developer:

• Lower financial risk, but a higher trust burden. They have to show, continuously, that the hours are producing value. Developers who are good at T&M make their progress easy to see.

Which model fits your project

Fixed price usually fits when:

• The project is well understood: a marketing website, a landing page, a redesign of an existing site with a known page list.
• You can write down every page, feature and integration before work starts.
• Your budget is a hard limit set by someone else, such as a board, a grant or a client.

Time-and-materials usually fits when:

• You're building something new whose details you'll learn along the way, such as a product, a custom dashboard or an AI feature.
• You expect to change priorities based on what users do once they see it.
• The work is ongoing: maintenance, conversion experiments, or improvements on a monthly retainer.

A common middle ground: a fixed price for a clearly defined first release, then T&M (or a monthly retainer) for everything after launch. You get certainty where it's achievable and flexibility where it's needed.

How scope changes are handled

Changes are normal. What matters is that both sides know the rules before the first one arrives.

• On fixed price, every change should go through a short, written change request: what's changing, what it costs, and how it affects the timeline. You approve it before work starts. A developer who quietly absorbs every change will eventually stop absorbing them, usually at the worst moment.
• On T&M, a change is simply a reprioritisation. The question becomes "what do we drop or postpone to make room?", not "what does this cost extra?". The cost shows up in the next invoice, so you should see the trade-off before you agree.

In both cases, ask for changes and approvals to be recorded somewhere you can both see, such as the project board, a shared document or email, rather than only in a call.

What a good fixed-scope quote must name

If you're comparing fixed-price quotes, a short, vague quote is not a cheaper quote. It's a quote that hasn't told you where the extra costs will come from. A good one names:

• Deliverables: every page, template, feature and integration, listed individually.
• What's excluded: copywriting, photography, hosting, third-party licences, data migration. Exclusions are as important as inclusions.
• Content responsibility: who supplies text and images, and by when.
• Rounds of revisions: how many rounds of design and content feedback are included.
• Acceptance criteria: how you'll both agree that something is "done".
• Browsers and devices supported: usually current versions of the main browsers, on phone and desktop.
• Timeline and dependencies: the schedule, and what happens to it if feedback or content arrives late.
• Payment milestones: what triggers each payment.
• Change process: how out-of-scope requests are quoted and approved.
• Ownership and handover: that you own the code, the domain and every account, and get full access at the end (or better, from day one).
• Post-launch support: a warranty period for bugs, and what ongoing support costs.

For a sense of how I scope and price work, see my pricing page.

A discovery phase for complex systems

For a custom system, such as a booking platform, a client portal or anything connecting several other tools, neither side can honestly fix a price on day one. Too much is unknown.

The answer is a discovery phase: a short, paid piece of work, priced on its own, whose only job is to remove the unknowns. A useful discovery phase typically produces:

• A written specification of features and user flows.
• A list of integrations, with any technical risks spelled out.
• Wireframes or a clickable prototype of the key screens.
• A phased estimate, often with a fixed price for the first phase.

You own what discovery produces. If you decide not to continue with the same developer, you can take the specification to someone else. That makes discovery the cheapest insurance you can buy on a large project: you spend a little to find out what the whole thing really costs before committing to it.

Questions to ask your developer

• "Which contract model do you recommend for this project, and why?" A good developer explains the risk, not just the price.
• "What exactly is excluded from this quote?"
• "How do you handle a change request? Can you show me an example of one?"
• (For T&M) "How will I see progress each week, and can we agree a monthly cap that you'll warn me before reaching?"
• (For fixed price) "How much buffer is in this estimate, and what would make it go over?"
• "Would a paid discovery phase make sense first? What would it produce, and would I own it?"

A developer who answers these openly is one you can work with under either model. One who gets defensive about exclusions or change requests is showing you, early, how disagreements will go later.

Next step

In short: fixed price fits work you can fully describe; time-and-materials fits work you'll discover; discovery turns the second into the first. Whichever you pick, the real protection is the same: a written scope, a clear change process, and regular, visible progress.

If you have a project in mind and aren't sure which model fits, tell me about it. I'll suggest a structure, and a discovery phase if the project needs one. You can also see how I approach web development projects.