All writing

Freelancing · · 2 min read

How I scope a fixed-price build without getting burned

Fixed price fails when the scope is a wish and the estimate is a guess. Four habits that keep the number honest for both sides.

SSunil MauryaFull-Stack Developer & AI Expert

Clients like fixed price because it's a number they can approve. Developers dislike it because it transfers all the risk. Both are right, and the disagreement is almost never about the rate — it's about how much was actually agreed.

Charge for the scoping

The estimate is the work. Turning a paragraph of ambition into a screen-by-screen build plan takes real hours, and doing it for free forces you to rush the one artefact that determines whether the project succeeds.

A short paid discovery — flows, data model, integrations, the list of things explicitly *not* included — produces a document the client owns. If they take it elsewhere, they got what they paid for. Usually they don't.

Write down what's out of scope

Every proposal lists what's included. Very few list what isn't, and that's where the arguments come from. Be specific:

  • Content and copy: who writes it, and by when.
  • Third-party accounts and their costs — payments, email, SMS, hosting.
  • Browser and device support, stated as a list, not "modern browsers".
  • Post-launch: what the warranty period covers, and what's billed separately.
  • Design rounds: how many, and what a "round" means.

Price the unknowns as unknowns

Some parts of a build genuinely can't be estimated until you're inside them — a legacy migration, an undocumented API, anything where a third party controls the answer. Padding the fixed price to cover that is a tax the client pays whether or not the risk lands.

Fixed price for the known work. Time and materials, with a cap, for the unknown work.

Say it plainly in the proposal and clients almost always agree — it reads as honesty, because it is.

Show progress weekly, in the product

Scope creep is rarely malicious. It's what happens when a client goes quiet for five weeks and then sees the build for the first time with all their assumptions intact.

A weekly deployed link and three lines of what changed catches misunderstandings while they're still an hour of work, not a fortnight. It's also the cheapest trust you will ever buy.

When to say no

If a client won't pay for scoping, won't put the exclusions in writing, and wants the number today — that's the shape of a project that ends badly for both of you. Walking away early is a business decision, not a failure.

Next article

Shipping AI features that survive production

A demo needs one good answer. A product needs a good answer on the worst input a real user will send you. Here's the gap, and how I close it before launch.