Fixed Quote vs Hourly: How a Solo Developer Prices a Web App

Ask ten developers how they price a project and you'll get ten different rates, but really only two models: hourly, or a fixed quote agreed before work starts. The difference isn't just accounting — it determines who absorbs the risk when the estimate turns out to be wrong.

The hidden cost of “hourly”

Hourly billing sounds fair — you only pay for time actually worked. In practice, it means every planning mistake, every unclear requirement, and every bit of scope that got glossed over in the sales call becomes your bill, not the developer's problem. The meter runs the same whether the work is going smoothly or the developer is stuck re-reading your spec for the third time.

Why agencies default to hourly

It's not malicious — it's risk transfer. Estimating software accurately before you've actually built any of it is genuinely hard, and hourly billing means the person doing the estimating doesn't have to get it exactly right. The client absorbs the gap between the estimate and reality. A fixed quote flips that: the developer has to get the estimate right, because they're the one who eats the difference if it runs long.

How a fixed quote actually works

A real fixed quote isn't a number pulled out of the air on the first call. It follows a specific sequence: a scoping conversation where you describe the product in plain words, a written breakdown of the deliverables translating that into specific features and pages, and only then a quote — tied to that written scope, not a vague sense of the project's size. “Done” is defined before the first line of code, not negotiated after the fact.

What happens when scope changes mid-project

Real projects change shape — that's not a failure of planning, it's normal. The difference with a fixed-quote model is that a genuinely new request (a feature that wasn't in the original written scope) becomes its own small, separate quote, agreed before it's built — not silent scope creep that erodes the original number, and not an excuse to reopen the whole budget. The original scope stays fixed; only additions get priced.

When hourly actually makes sense

Hourly isn't wrong everywhere. It's the right model for open-ended maintenance, ongoing feature work on a live product, or a retainer where the point is having a developer on call rather than shipping one defined thing. What it's a poor fit for is a new build with a real endpoint — exactly the situation where a fixed quote protects you.

Questions to ask before agreeing to hourly

• Is there a not-to-exceed cap on the total hours, in writing?
• Who absorbs the cost if the original estimate turns out to be wrong?
• Can you get a written breakdown of deliverables before the meter starts, even if the final price is hourly?
• What does “done” mean, and who decides when it's been reached?

If those questions get vague answers, that's the actual signal — not the hourly rate itself, but whether anyone is willing to define the finish line before you start paying for the race.