Fixed Price vs Hourly Software Development: What Protects Founders

With hourly billing, you carry the risk of the project taking longer. With a fixed price, the developer does. Fixed price protects founders best when the scope can be written down; hourly is more honest when it genuinely can't. Either way, the protection comes from the contract: a written scope, acceptance criteria and a rule that every change is priced before it's built.

Disclosure: I run Ship It Live and have only ever quoted fixed prices. I've tried to be fair to hourly below, including when it's the better choice.

What's the difference between fixed price and hourly?

The difference is who pays when the work takes longer than expected. Hourly (often called "time and materials") bills for the time spent, so overruns are yours. Fixed price agrees one number for a defined scope, so overruns are the developer's.

	Hourly / time and materials	Fixed price
Who carries the overrun risk	You	The developer
What you know up front	A rate and an estimate	A price and a scope
Incentive on speed	Slower work earns more	Faster work earns more
Changing your mind mid-project	Easy; you pay for the time	Possible; each change is quoted first
Cost of questions and calls	Every call is billable	Included
Upfront work needed	Little	A clear written scope
Best when	Scope can't be known yet	Scope can be written down

How often do software projects overrun?

Often enough that you should plan for it. Overruns aren't rare accidents. They're a pattern.

• The Project Management Institute's 2018 Pulse of the Profession found that 52% of projects completed in the previous 12 months experienced scope creep, up from 43% five years earlier.
• Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects for Harvard Business Review. The average cost overrun was 27%, but one in six projects overran its cost by 200% on average, and its schedule by almost 70% (September 2011).

The second finding matters most for founders. The danger isn't the average overrun. It's the one-in-six project that triples in cost, because a startup usually can't survive it. Under hourly billing, that tail risk is entirely yours.

"It always takes longer than you expect, even when you take into account Hofstadter's Law." — Douglas Hofstadter, Gödel, Escher, Bach (1979)

Why does hourly billing go wrong?

Hourly billing isn't dishonest. Its incentives just point the wrong way, even when everyone means well.

• It pays more for slower work. An experienced developer who finishes in 40 hours earns less than a learner who takes 90 on your project. As I put it on our no hourly rates page: "Experience should make you cheaper to hire, not more expensive."
• The estimate isn't a commitment. An hourly estimate is a forecast. When it's wrong, the invoice changes, not the estimate.
• It taxes communication. When every call is billable, founders batch questions, sit on doubts and approve things they're unsure about. The conversations that prevent expensive mistakes are the first ones cut.
• Scope grows a few hours at a time. Each new idea is "just a quick change". There's no moment where anyone has to decide whether it's worth the money.

Why does fixed price go wrong?

Fixed price has its own failure modes, and they're mostly about a vague scope. Watch for these:

• A vague scope priced anyway. If the scope says "user dashboard", the developer will build the smallest thing that matches the words, and you'll argue about what you meant.
• Padding. A developer carrying the risk prices some uncertainty in. That's fair, but you should still compare like with like.
• Change requests used as profit. A low fixed price with expensive changes is hourly billing in disguise.
• Quality cut to protect margin. If the developer misjudged the effort, the temptation is to cut corners. Acceptance criteria are your protection.

When is hourly the right choice?

Hourly is the honest choice when nobody can write the scope down yet: early research, a technical unknown, or ongoing work where priorities change weekly. Anyone who puts a fixed number on an unknowable scope is either padding heavily or planning to renegotiate.

There's a middle path that gets you to a fixed price safely: pay for the scoping on its own. A short, fixed-price discovery phase produces a written scope, the key user flows and a build plan. After that, the build can be quoted with confidence. Our five-day product discovery sprint is $700, ends with a fixed quote, and the fee comes off the build if you book within 30 days.

What should a fixed-price contract include?

Seven things. Without them, "fixed price" is a number without a definition:

1. A written scope, including a list of what's not included. The exclusions prevent most disputes.
2. Acceptance criteria for each feature, written so a non-technical person can check them. "A new user can sign up, start a trial and be charged on day 15."
3. A change process. Any change outside the scope is described and priced before it's built, and you can say no.
4. What revisions are included, so feedback is never a negotiation.
5. A timeline with dependencies, including what you must provide and when (content, access, decisions).
6. Payment milestones, usually a portion up front and the balance on delivery, tied to the same fixed number.
7. Ownership: the source code, design files and accounts transfer to you.

What should an hourly contract include?

If you do go hourly, these terms protect you:

• A weekly cap that can't be exceeded without your written approval
• Itemised time reports, weekly
• A not-to-exceed estimate per feature, re-agreed if it's going to be broken
• The right to stop at any milestone and keep everything built so far
• The same ownership terms as above

Which protects founders better?

For most founders building a first product, a fixed price against a written scope protects better, because it moves the overrun risk, including the one-in-six "black swan" risk, off the party least able to absorb it. Hourly is better only when the scope truly can't be written down, and then it should be capped.

The deeper point is that neither billing model protects you on its own. A clear scope does. If you can't yet describe what you're building, that's the first thing to pay for.

Sources checked on 5 October 2026: PMI Pulse of the Profession 2018 (via Epicflow's summary) and Flyvbjerg and Budzier, Harvard Business Review, September 2011. Questions? Talk to the Ship It Live team.