Fixed scope or time and materials? How we price web projects

Every web project pricing model is really just a decision about who absorbs the risk when the estimate turns out to be wrong — and estimates are always at least a little wrong. There are two honest ways to handle that, and one dishonest one.

Time and materials: the client absorbs the risk

You pay for actual hours worked. If the project takes longer than expected, you pay more. This is genuinely the right model when the scope is expected to change — an evolving product, a team augmentation engagement, ongoing care work after launch. The risk sits with the client because the client is the one who benefits from the flexibility.

Fixed scope: the studio absorbs the risk

You agree on a defined set of deliverables for a defined price before work starts. If it takes us longer than estimated, that's our estimating error to absorb, not your budget overrun. This only works honestly when the scope is genuinely locked before the quote — which is exactly why we do a discovery call and a written scope document before any fixed price is given, not after.

The dishonest version

The dishonest pattern isn't either model — it's switching from fixed-sounding language to time-and-materials billing once the client is already committed, via scope so vague that almost anything counts as "out of scope" the moment it's inconvenient. If a fixed quote exists, every deliverable in it should be specific enough that both sides can tell, without argument, whether it's been delivered.

How we actually decide

Website Consultancy and Website Development are fixed scope by default — the deliverables are well-understood and don't usually change mid-project once the brief is locked.

Full-stack Application Development starts fixed-scope for discovery and architecture, then usually moves to two-week sprints, billed per sprint, once real build work starts — because product scope legitimately evolves once people can click on something real, and pretending otherwise just pushes the disagreement to later, at higher cost.

Full-stack with AI integration is scoped per workflow rather than per project, because the honest estimate for "add a chatbot" and "add a chatbot that handles refunds against our live inventory" are wildly different numbers, and conflating them is exactly the kind of vague scope we try not to write.

In every case, you get the actual number — a real range, not a published price list — after one discovery call, before you've committed to anything.