Every client asks this eventually, usually after getting two very different quotes: one fixed, one hourly, both from people who seem competent. Here is how each model actually behaves when the project gets real.
Fixed price, how it actually works
You pay an agreed amount for a written scope. Done well, this is the client-friendliest model that exists:
- You know the total before you commit
- The developer eats the cost of their own bad estimates (incentive to estimate honestly and work efficiently)
- Conversations are about outcomes, not billed minutes
The catch: fixed price is only as strong as the scope document. "A website for my restaurant, like modern ones" is not a scope. It is a blank check with a fight at the end. A real scope lists pages, features, content responsibilities, revision rounds, and what happens when you change your mind.
Hourly, how it actually works
You pay for time, usually with weekly or biweekly reports. Honest in one direction: you only pay for work done. Dangerous in another: nobody is incentivized to be fast, and the total is unknown until it is over.
Hourly works when the work genuinely cannot be scoped: ongoing maintenance, bug fixing old code nobody documented, exploratory work. It fails as a model for building a defined thing, because "defined" is exactly what you want the price to be.
The failure modes nobody warns you about
Fixed price fails by conflict. The scope was vague, expectations drifted, and the end of the project becomes a negotiation. The developer pads the next quote; you feel nickel-and-dimed on changes. Both sides lose.
Hourly fails by drift. Week 6 arrives and the site is "80% done" the same way it was in week 4. Nobody is lying. There was just never a finish line to measure against.
What I actually use, and why
Fixed price per milestone. The project is split into stages (design, build, launch), each scoped and priced separately, each paid on delivery of something you can see and click. Changes between milestones go through a one-paragraph change request with a price, approved before work happens.
You get the certainty of fixed pricing without the giant upfront commitment, and the developer (me) stays motivated to estimate well. This is also, not coincidentally, how you stay friends with your developer.
Questions that reveal which model a developer should use on your project
- Can you describe exactly what "done" looks like? If yes, ask for fixed price.
- Is this built on an existing system or something old and messy? Old and messy means hourly or a discovery phase first.
- Do you expect to change direction based on user feedback? Then time and materials with a cap, or short fixed sprints.
- Is there a hard budget ceiling? Say so upfront. A good developer designs the scope to fit it; a bad one hides the problem until week 5.
The one-sentence version
Fixed price rewards clear thinking, hourly rewards honest uncertainty, and the client who knows which situation they are in always gets the better deal.
If you are staring at two quotes right now and cannot tell which one is the fair one, send me both. I will translate the jargon and flag anything weird, no strings attached.