Fixed Price vs Time & Materials: How Web Projects Should Be Priced

Every web project quote answers one question before any other: who carries the risk when things take longer than expected? That is really what "fixed price" versus "time & materials" (hourly) is about. Not fairness. Not tradition. Risk allocation.

Most small businesses never get told this. They get a quote, a payment schedule, and a signature line. This article explains what each model actually incentivises, where hourly billing quietly hurts smaller clients, what fixed pricing demands from both sides, and which contract clauses should make you walk away.

The two models in one table

	Fixed price	Time & materials (hourly)
You pay for	An agreed outcome	Hours worked
Overrun risk sits with	The developer	You
Scope	Defined upfront, changes cost extra	Flexible, evolves as you go
Budget certainty	High	Low to none
Developer's incentive	Finish efficiently	Log more hours
Best for	Defined projects: sites, stores, MVPs	Ongoing work, genuine R&D, embedded team roles

Neither model is dishonest by nature. Both can be abused. The question is which failure mode you can afford.

What hourly billing really incentivises

Time & materials sounds fair: you pay for exactly the work done. In practice, three things work against a small client.

The meter has no ceiling. A typical estimate of "80–120 hours" at €60/hour means your budget is somewhere between €4,800 and €7,200 — a 50% spread before anything unexpected happens. And "unexpected" is the norm in software. When the project hits hour 121, the invoice keeps running and your leverage is gone: you have paid for most of a website you cannot use yet.

Efficiency is penalised. A developer who solves your problem in 4 hours bills less than one who takes 12. Nobody consciously slows down, but there is no structural reward for speed, reuse, or saying "you don't need that feature." The incentive gradient points toward more hours, not better outcomes.

You cannot audit what you cannot see. Was that "6 hours of debugging" reasonable? Unless you employ developers yourself, you have no way to know. Hourly billing asks non-technical clients to supervise technical time — the one thing they are least equipped to do.

Hourly is the right model when the work is genuinely open-ended: a long-running retainer, exploratory prototyping, or a developer embedded in your team where you direct the work daily. For a defined deliverable — "I need a website that does X" — it transfers all estimation risk to the party least able to price it.

What fixed price really incentivises

Fixed price flips the risk. If the developer underestimated, they eat the difference. That creates its own pressures, and you should know them:

• The incentive to cut corners. A developer losing money on your project may quietly reduce quality where you cannot see it — skipped tests, no documentation, fragile shortcuts.
• The incentive to inflate the quote. Some providers price in a fat risk buffer, so you pay for overruns that never happen.
• Scope-change friction. Every "small tweak" becomes a negotiation, because the developer's margin depends on the fence around the scope.

The honest version of fixed pricing solves this differently: accurate estimation. A developer who has built the same category of project many times — and whose tooling makes delivery fast — does not need a 40% buffer, because the estimate is not a guess. That is why fixed pricing works best with specialists and worst with generalists quoting something they have never built.

What fixed scope requires — from both sides

Fixed price is a two-way contract. It fails when either side treats it as one-way.

The developer must provide:

1. A written scope: pages, features, integrations, and — critically — what is excluded.
2. A delivery date, not "4–6 weeks from kickoff, dependencies permitting."
3. A defined revision allowance (e.g., two revision rounds on design).
4. A written process and price basis for changes before the project starts.

You must provide:

1. Content, brand assets, and access credentials by an agreed date. Late content is the #1 cause of "the agency is slow."
2. One decision-maker. Committees renegotiate scope by accident.
3. Feedback within an agreed window (48–72 hours is reasonable).
4. Acceptance of the scope you signed. "While you're at it..." is a change request, not a favour.

If you cannot define what you want yet, you are not ready for fixed price — and a good developer will tell you so and offer a short paid discovery phase instead of a padded guess.

Change-request etiquette

Changes are normal; roughly every project has them. The difference between a smooth project and a hostile one is the process:

• Ask for the impact in writing. A professional answer looks like: "Adding member login: +€X, +Y days. Confirm and we schedule it."
• Batch small changes. Ten one-line emails cost more coordination than one weekly list.
• Expect small goodwill, not free features. Fixing a typo is goodwill. A new page template is scope.
• Watch how change #1 is handled. If the first change request produces a clear quote in 24 hours, you chose well.

Red flags in web contracts

Walk away, or renegotiate, if you see:

• Hourly billing with no cap and no estimate. You are signing a blank cheque.
• Fixed price with no written scope. That is not fixed price; it is a future argument.
• 50–100% payment upfront. Standard is 30–50% to start, remainder tied to milestones or delivery.
• No mention of who owns the code and design. On final payment, you should own the deliverables. Full stop.
• Hosting, domain, or CMS locked to the provider with no exit clause. You should be able to leave with your site.
• "Unlimited revisions." Nobody offers unlimited anything profitably; it signals either a padded price or a provider who will disappear at revision three.
• No warranty period. 30–90 days of bug fixes after launch is normal.

Where we stand

At Feitura we quote fixed prices — for essential sites, online stores, and custom applications — because our AI-accelerated delivery pipeline makes estimates reliable enough that we can carry the overrun risk instead of you. Scope, timeline, and change-request pricing go in writing before we start. Ongoing maintenance runs as a flat monthly plan, because predictable costs should not end at launch.

That is not the only legitimate way to price web work. But whichever model you are offered, you now know which questions to ask: who carries the overrun, what exactly is in scope, and what happens when — not if — something changes.

If you want to see what a fixed, written quote looks like for your project, request an estimate and get a scoped price with a delivery date, not an hourly guess.