What is the difference between fixed-price and hourly billing for software?

The difference is who pays when the estimate is wrong

Most comparisons of these two models lead with budget certainty against flexibility. That is the symptom. The cause is simpler: somebody has to carry the risk that the work takes longer than anyone thought, and the billing model is the decision about who that is.

Under hourly billing, the hours are the invoice. If a piece of work turns out to be three times harder than it looked, the bill is three times larger, and the buyer absorbs it. Under a fixed price, the number was agreed before anyone knew, and the vendor absorbs it. Everything else people say about these models follows from that one line.

It also explains the honest objection to fixed price, which is worth stating plainly: a vendor who carries that risk prices it. Part of what you pay for in a fixed bid is the vendor's uncertainty, and if the project turns out to be easy, you paid for uncertainty that never materialized. That is the trade. You are buying a known number instead of a possibly smaller one.

What a fixed price needs in order to hold

A fixed price that is really an hourly estimate in a confident tone is worse than hourly billing, because it collapses at the first surprise and you find out in month three. Three things have to exist in writing before the number means anything.

• A scoping step that produces a definition of done. Not a feature list. A description specific enough that two people can disagree about whether something is finished and then settle it by reading the document. If the scope was written from a sales call, nobody has looked hard enough at the work to price it.
• An explicit answer to who absorbs an estimation miss. This is the question the model exists to answer, so it should not have to be inferred. Ask for it in a sentence.
• A written change process. Scope does move on real projects, and a fixed price does not prevent that. What it should do is separate two different events: a change is you asking for something that was not in the scope, and a correction is the vendor having misjudged something that was. Those get handled differently, and a proposal that treats them the same is a proposal where every surprise becomes your invoice.

Four questions to ask any vendor quoting you a fixed price

• What did you do before producing this number? A fixed price is only as good as the work behind it. If nothing preceded the quote, the number is a guess with a signature on it.
• What is the written definition of done? Ask to see it. If the answer is the proposal's bullet list, that is not a definition of done.
• If you underestimated something, whose cost is that? One sentence. There is a correct answer and it should be easy to say.
• What specifically would trigger a change order, and what specifically would not? The second half is the one that matters. Any vendor can list what counts as a change. Fewer will commit to what does not.

When hourly is the right answer

We work fixed-price, and there are still cases where asking us for a fixed price would be the wrong move. Naming them is more useful than pretending one model wins everywhere.

• Nobody has been inside the system yet. An undocumented third-party API, a vendor integration with no sandbox, a legacy database whose behavior is known only to people who have left. Pricing that scope means pricing the worst case, and you would pay for the worst case whether or not it happens.
• The deliverable is a finding, not a feature. "Can this model do the job at an acceptable error rate" is a real question with real value, and it has no definition of done, because the answer might be no. Fixing a price on it means fixing a price on an outcome nobody can promise.
• The direction changes faster than a scope can be written. If priorities move after every customer conversation, a written scope is stale before it is signed, and you will spend the engagement processing changes instead of shipping.
• The work is too small to be worth scoping. A one-off script, a small fix, an afternoon of investigation. The scoping step would cost more than the work.

A common and sensible arrangement is both in sequence: buy the uncertain part hourly until it is understood, then fix the price on the build once it can be described. That is the same logic as pricing a build from an audit rather than from a sales call.

Retainers are a third model, not a version of hourly

The fixed-price question is about a build, and builds end. Ongoing work after launch is a separate question with a separate answer, which is why framing this as a binary misleads. A monthly retainer buys continuous availability rather than a defined deliverable, which is the right shape for maintenance, iteration and support, where the work cannot be enumerated in advance and what you actually need is that somebody is there.

How Code and Trust bills

Most large builds are fixed-price, with a monthly retainer after launch. Not every engagement is, and hourly billing exists here for the cases above.

A fixed-price engagement starts with a workflow audit, which precedes the scope and the price. The audit is what makes the number defensible: we scope and price from it rather than from a call. You get a written scope document with the deliverables before work begins, and there are no change orders for scope creep that results from our own estimation errors. Every engagement includes 90 days of post-launch support, covering bug fixes in the delivered scope, performance monitoring, deployment assistance and team handoff documentation.

For what an engagement costs, see the estimate page and what custom software development costs, which is where the current figures are published.