Fixed-Price vs Hourly Software Development: Who Carries the Risk

Every software pricing model is really a sentence about who eats the overrun. Hourly says: if it takes twice as long, you pay twice as much. Fixed price says: if it takes twice as long, that is my problem, not yours. That single difference decides more about your build than the headline rate ever will. A $90 per hour developer can cost you more than a $150 per hour one, because the cheaper rate hides who is carrying the risk when the estimate is wrong. And the estimate is almost always wrong.

This is a founder's guide to picking the model, not the vendor's guide to defending one. I will tell you exactly where fixed price fails too, because it fails badly when one condition is missing.

How hourly actually behaves

Hourly billing sounds fair. You pay for time worked, the developer gets paid for effort, no one games a fixed number. In practice the incentives bend in a direction that does not favor you.

• Efficiency is not rewarded. The faster the developer works, the less they earn. Nobody is consciously dishonest, but a model that pays more for slower work does not select for speed.
• The estimate is a vibe, not a contract. "Roughly 80 hours" is a hope. When it becomes 140, that is not a breach. That is just Tuesday. The 75 percent overrun is yours.
• You manage the clock, not the outcome. Your job becomes watching hours instead of watching the product. You start hesitating to ask for the right thing because every conversation is metered.
• Scope creep has no brake. With no fixed total, "while you're in there, can you also..." has no cost ceiling. It just adds hours.

Hourly is honest about effort and silent about outcome. You are buying time and hoping it converts to a finished app.

How fixed price actually behaves

Fixed price flips the risk. The number is agreed before work starts, and if the build runs long, the builder absorbs it. That changes the incentives in your favor.

• Speed is rewarded. The faster it ships at the agreed quality, the better for the builder. Now the incentive points the same way you do.
• Overrun risk is theirs. If the build is harder than expected, that is priced into the quote or eaten by the builder. Your budget does not move.
• You manage outcomes, not the clock. Conversations are about whether the product is right, not how many hours a question costs.

There is exactly one condition that makes this work, and it is the whole game: scope has to be locked before the price is fixed. A fixed price on a vague brief is not protection. It is a trap with a number on it.

The trap: fixed price on unlocked scope

Here is how the bad version works. An agency quotes a low fixed number against a one-paragraph brief. You sign, relieved. Then every real requirement that the paragraph did not mention arrives as a change order at a much higher rate. The low fixed price was the anchor. The change orders were the actual business model. You end up paying more than hourly would have cost, and you feel cornered doing it.

So the real question is not "fixed or hourly." It is: is the scope written down in enough detail that the fixed number means something? If yes, fixed price moves the risk to the builder. If no, fixed price is just hourly with a worse temper and a surprise at the end.

A fixed price on unlocked scope is not a price. It is an anchor, and the change orders are the real invoice.

A worked example on the same build

Take one concrete project: a booking tool for a solo consultant. Five screens, Stripe payments, email confirmations, an admin view. Watch how the same build behaves under each model.

| Model | Quoted | Likely final | Who eats the overrun | |-------|--------|--------------|----------------------| | Hourly, $100/hr, "~70 hrs" | ~$7,000 | $9,000 to $14,000 | You, every extra hour | | Fixed, unlocked scope | $4,500 | $4,500 + change orders | You, via adders | | Fixed, scope locked | $3,950 | $3,950 | The builder |

Same screens, same Stripe, same emails. The number you actually pay swings by thousands based purely on which model carries the risk and whether the scope was nailed down first. The locked-scope fixed price is both the lowest and the only one with a number you can trust, because the work was written down before the price was set. See the full ranges in the 2026 cost guide.

What "locked scope" actually requires

Locking scope is not a vibe; it is a checklist. Before a fixed number is honest, you need clear answers to:

• Screens. How many, and what is on each one. "A few screens" is not a count.
• Auth and roles. Do users log in? One role or several? Admin views?
• Payments. Stripe Checkout, subscriptions, or none. Webhooks change the work.
• Integrations. Every external system named, because each is its own slice.
• Data model. What gets stored, and how complex the relationships are.

Most quoting processes skip this and call it "discovery," then bill the discovery. Read how to scope an MVP for the full version of this checklist, and the fixed-price founder's guide for how to buy fixed without getting burned.

How we make the fixed number honest

The reason most builders avoid fixed price is that scoping is hard work, and a wrong scope means they eat the overrun. We fixed that with structure instead of optimism.

You describe the app in the scope chat. The AI runs the checklist above as a structured interview, asking the auth and payments and integration questions until it can fill a complete spec. Then a deterministic pricing engine maps that spec to a fixed quote from our published offers. The model extracts scope; it never invents the price. That separation is the point. The price is not a salesperson's guess and it is not a per-hour meter. It is the same engine, every time, mapping locked scope to a number you see before you pay.

If your scope exceeds a tier, the chat says so, and you either trim it or move up a package. Scope changes after lock are quoted as named add-ons, never as surprise hours. That is the difference between an honest fixed price and an anchor.

When hourly is actually the right model

I am not against hourly. It is the correct model when the work genuinely cannot be scoped yet.

Pick hourly for open-ended research where the definition of done is unknown, for embedded daily collaboration where you want someone in your standups indefinitely, or for ongoing maintenance with unpredictable, small requests. In those cases a fixed price would be dishonest, because there is no stable scope to fix it against. For steady post-launch iteration specifically, a flat monthly dev lane beats both: not hourly, not a per-project quote, just a predictable monthly rate with one active request at a time.

The honest take

Stop comparing hourly rates to fixed totals as if they are the same kind of number. They answer different questions. The real decision is who carries the risk when the estimate is wrong, and the only thing that makes a fixed price trustworthy is locked scope underneath it.

If your build is a defined first version, you want a fixed price on locked scope, and you want to see the number before you pay. Describe the app at /start, answer the scope questions honestly, and the price takes shape as you talk. Compare the tiers on pricing. No anchor, no change-order ambush, no clock to watch.