Fixed-Price Software Development vs Hourly Billing: Why Hourly Is Broken

I have not billed by the hour in three years. Every project we ship is fixed-fee, agreed before work starts, paid in milestones. Clients sometimes resist this. They want hourly because hourly feels safer, they think they are buying optionality. They are not. They are buying a set of incentives that work against them.

This is not a new argument. Consultants have been making the case against hourly for decades. What is new is that for software work specifically, the case has gotten overwhelming. And yet most studios still quote in hours. So this is the version of the argument I make when a client asks why we work the way we do.

What hourly billing actually rewards

Hourly billing rewards the studio for taking longer. This is not a moral failure. It is arithmetic. If a senior engineer can ship a feature in eight hours and a junior in forty, the studio that bills hourly makes five times more money assigning the junior. The senior is punished for being fast.

Studios that operate on hourly fees develop the habit of staffing projects with the people who cannot finish quickly. Not always consciously. But the math runs in the background of every staffing decision, and over time it shapes the studio.

Fixed-fee inverts this. If the price is set, the studio is rewarded for shipping faster. The senior engineer who finishes in eight hours is now five times more profitable than the junior. Suddenly the studio wants the senior on every project. The client gets better work, faster, for the same price.

What hourly billing pretends to be

The pitch for hourly is that the client only pays for what is delivered. This is not what hourly actually does. Hourly bills for time spent, which is not the same as work delivered. The studio bills for the hours its team logged. Whether those hours produced anything is a separate question.

I have read hundreds of hourly invoices. Discovery call: 1.5h. Internal review: 2h. Slack discussion: 0.75h. These are real charges I have seen on real invoices. None of them produced anything the client can use. All of them were billed.

Hourly billing is a tax on the client paid every time the studio thinks about the project.

The client cannot push back on these line items because they have no way to verify. Was the internal review necessary? Was the Slack discussion productive? The studio knows. The client does not. The information asymmetry is the business model.

What fixed-fee requires from the studio

To quote fixed-fee, the studio has to actually understand the work. This sounds obvious. It is not. Hourly billing lets studios stay vague about scope and figure it out as they go. Fixed-fee forces the studio to do its homework before quoting.

We spend two to four hours per prospect before quoting. Not free consulting, quoting. Reading the codebase if there is one. Understanding the data model. Mapping the user flows. By the time we send a number, we know within twenty percent what the work will cost us to do. We absorb the twenty percent variance. The client absorbs none of it.

This is more work for us than sending an hourly rate card. It is also the only honest way to do this. A studio that quotes fixed-fee without doing this work either overcharges to be safe, or underquotes and resents the client by month two. Neither is sustainable.

What fixed-fee requires from the client

Fixed-fee also requires the client to decide what they want before work starts. This is where most fixed-fee projects fail: the client agrees to a scope, then changes their mind in week three.

The honest answer here is a written change-order process. New scope is a new quote. Not negotiable, not absorbed quietly into the existing project. We have a template. The client signs it. The work happens. This sounds bureaucratic. It is the opposite, it is the thing that prevents the slow resentment that builds when a studio absorbs scope creep silently.

Clients sometimes push back on this. Can't you just do it? The honest answer is no. Just doing it is how every project I have seen go badly went badly. The change order is the friction that keeps both sides honest.

When fixed-fee fails

Fixed-fee fails on two kinds of projects.

1. True R&D. If neither the studio nor the client knows what is being built, fixed-fee cannot be priced. The right model here is a time-boxed exploration phase, billed as a flat fee, that ends with a written scope that can be fixed-fee priced. Skip the exploration and pretend the scope is known, and the project goes badly for both sides.
2. Long-term retained engineering. If we are embedded with a product team for six months, fixed-fee per feature creates perverse incentives in the other direction. For ongoing partnership, we quote a monthly retainer with a defined output. This is closer to a salary than a per-project fee. It works because the relationship is long.

For everything else, websites, brand identities, scoped software builds, discovery sprints, fixed-fee is the answer. It aligns incentives, it forces clarity, and it makes the conversation about value instead of hours.

What we charge for

We charge for outcomes, not effort. A client who hires us is hiring us to get a specific thing done. The price reflects what that thing is worth. Sometimes the work takes us less time than we expected. The price stays the same. Sometimes it takes us more. The price stays the same. The client is not paying for our time. They are paying for the thing that is delivered.

This is the deal. It only works if both sides take it seriously. We do. Most clients, once they have done a fixed-fee project with us, never go back. The clarity is worth too much.