What does a fixed price for software actually cover?

A fixed price covers the work of deciding what correct means, encoding those decisions as checks that can fail, building until they pass, and owning the result through production. It does not buy a fixed number of hours, because hours were always a proxy for effort rather than a measure of value, and the proxy stopped tracking reality once a machine took over the typing.

Is fixed-price or time-and-materials better for custom software?

Each answers a different question. Fixed price answers "what will this cost me", and it requires the scope to be written down well enough that both sides can tell when it is met. Time and materials answers "how do we work together while we find out", and it suits genuine discovery where nobody can state the requirement yet. The failure mode is using fixed price on work that is really discovery, which produces either a padded number or a fight.

Why has the price not fallen now that AI writes the code?

Part of it has. The cost of producing a given piece of working software is lower, and that is exactly the saving we pass into the price rather than the margin. What has not fallen is the cost of deciding what to build, defining correct behaviour precisely, and standing behind the result, and those were always the parts that determined whether a project succeeded.

How should unknowns be priced?

Name them, price the work of resolving them separately, and attach a date by which the answer is needed. Three or four genuine unknowns is normal on any real build. A quote that contains none has not removed the risk, it has moved the risk to the buyer without saying so.

What should a fixed-price quote contain?

It should contain the list of statements that must be true when the work is done, the checks that prove each one, the named unknowns with their decision dates, what happens when scope changes, and what the vendor is responsible for after release. A number with a paragraph of description above it is an invitation to argue later.

How do you stop a fixed-price build from turning into scope arguments?

Write the acceptance criteria as things that can be checked automatically, before any code is written, and agree them in writing. Most scope arguments are really disagreements about what a sentence in the original document meant, and a sentence that has been turned into a passing or failing check cannot be reinterpreted six weeks later.

Should the specification be a separate paid engagement?

Often yes, and it is usually the most valuable money a buyer spends. A specification written well enough to price against is a real deliverable that the buyer keeps regardless of who builds the software, and it converts an unpriceable request into something two or three vendors can quote on comparable terms.

What happens to the price when requirements change mid-build?

Requirements change on every project, so the contract should say how change is handled rather than pretending it will not happen. The workable version prices each change against the checks it adds or invalidates, so the conversation is about specific work rather than about goodwill, and neither side is arguing from memory about what was originally meant.

Does a cheaper build mean lower quality?

It depends entirely on where the saving came from. A saving that comes from generating the implementation faster leaves the verification intact. A saving that comes from skipping the specification, the checks, or the responsibility after release is a deferred cost that arrives later with interest. Ask which one you are being offered.

How can a buyer verify a fixed price is reasonable?

Ask what the money buys in units you can inspect: the list of behaviours that will be proven, the checks that prove them, and the support commitment after release. Two quotes with the same number can differ enormously in what they include, and the difference is almost never visible in the headline figure.

How to price a fixed-scope software build: Reveneau

There is a question buyers of custom software have started asking, and it is a fair one. If a machine writes the code, why does the price look roughly the same as it did before?

The honest answer has two parts. Part of the price has fallen, and that is deliberate: we use AI instead of hiring more engineers, so a given build takes a small team, and that saving goes into the client's price rather than the margin. But the part of the price that did not fall is the part that was always doing the real work. It was just hidden inside an hourly rate where nobody had to look at it.

This piece is about what a fixed price for software actually covers now, and how to write one that survives contact with a real project.

The unit that stopped working

Software has been priced in hours for forty years. Hours were never the thing being sold. They were a proxy: a way of estimating effort when effort and typing were roughly proportional.

That proportion is gone. An implementation that took a week of typing can now be produced in an afternoon, and rewritten four more times before dinner. If you keep pricing in hours, one of two things happens. You quote honestly and the number looks implausibly low next to the value of the software, or you pad the hours back up to something that feels right and now your invoice is a work of fiction.

Neither is a good position to negotiate from. The fix is to price the parts that did not change.

What actually costs money now

Three things, in order of how much they matter.

Deciding what correct means. Somebody has to turn "users should be able to export their data" into a list of statements precise enough that a machine can check them. Which users. Which data. What happens to a record that is half-deleted. What the export does when it is forty gigabytes. What the person sees when it fails at eighty percent.

This work did not get cheaper. It got more consequential, because a vague sentence now becomes confident, plausible, wrong code within minutes, and it looks finished. We wrote about this at length in how to write an acceptance test a machine can run, which is the practical version of the same argument.

Proving it. Every statement from the first step becomes an automated check, written before the implementation, that fails against the current codebase and passes when the work is done. This is the durable asset in any engagement. The implementation is disposable and gets rewritten; the checks survive every rewrite and are still running in three years.

Owning what happens next. Production is where software meets the conditions nobody specified. A price that ends at handover is a deposit, and the buyer discovers as much about six weeks later.

Write the scope as checks, not as prose

The single highest-leverage change to how a fixed-price engagement is written: replace the bulleted feature list with a list of statements that can be proven true or false.

Compare these two lines from a scope document.

The system will support bulk import of customer records.

A CSV with up to 100,000 rows uploads and completes within five minutes. Rows failing validation are reported by row number with the specific failing field, and no partial import is committed. An import interrupted by a server restart resumes or rolls back cleanly, never leaving duplicate records.

The first sentence is where scope disputes come from. Six weeks in, the buyer means one thing by "support bulk import" and the vendor means another, and both of them are reading the same words honestly. The second version cannot be reinterpreted. It either happens or it does not, and a machine can tell you which.

This is more work to write. That is the point: the work has to happen somewhere, and doing it before the price is agreed is enormously cheaper than doing it during an argument in month two.

Price the unknowns instead of hiding them

Every real build has things nobody can know yet. The third-party API whose rate limits are undocumented. The legacy database whose data quality nobody has measured. The compliance requirement that depends on an answer the client's lawyer has not given.

There are two ways to handle these in a fixed price. The common one is to pad the number until the padding covers the worst case, which means the buyer pays for a risk that probably will not happen, and the vendor never has to explain what the padding was for.

The better one is to name each unknown in the quote, price the work of resolving it separately, and attach a date by which the answer is needed. Three or four named unknowns on a substantial build is normal and healthy.

Buyers, here is the thing worth internalising: a quote with no unknowns listed is not a more confident quote. The risk did not evaporate because nobody wrote it down. It moved quietly onto your side of the contract. When you compare two proposals and one has a shorter risk section, you may be reading the less careful vendor rather than the better one.

Handling change without a fight

Requirements change on every project. A contract that assumes otherwise is not protecting anyone.

The mechanism that works is to price a change against the checks it adds or invalidates. A new requirement means new statements about correct behaviour, which means new checks, which is a concrete unit of work both sides can look at. A changed requirement means existing checks become wrong, and rewriting them plus the code they protect is also concrete.

What this replaces is the usual conversation, where two parties argue from memory about what a paragraph written in July was supposed to mean, and the outcome depends on who is more willing to damage the relationship. Our guide to negotiating a software contract you can verify goes further into the contract language.

The specification is worth buying on its own

For anything substantial, the sequence that produces the best outcome is to pay for the specification as a separate, smaller engagement first, then price the build against it.

The buyer gets three things. A document precise enough that two or three vendors can quote on genuinely comparable terms, rather than each guessing at a different project. An artefact they keep regardless of who builds it. And an early, cheap read on whether the vendor can think clearly, which is much more predictive than any sales conversation.

The vendor gets to quote on something real. A fixed price against a vague brief is a gamble, and the rational response to a gamble is to price the bad outcome, which makes the number worse for everyone.

What the buyer should ask for

If you are evaluating a fixed price for custom software, four questions surface most of what matters.

What list of behaviours will be proven, and how? You want to see statements and the checks attached to them. A feature list is not an answer.

What are the unknowns, and when do you need answers? If none are named, ask again. If none are named the second time, that tells you something.

What happens after release, and for how long? Software does not finish. Find out what the number covers past the launch date.

What would make this price wrong? A vendor who can answer this specifically has thought about the project. A vendor who says nothing would has not.

Two quotes carrying the same number can differ enormously in what they include, and that difference is almost never visible in the headline figure. The number is the least informative part of a proposal. It is just the only part that is easy to compare, which is why it gets all the attention.

Sources

2025 DORA report announcement, Google Cloud: drawn from roughly 5,000 respondents; AI adoption relates positively to throughput and negatively to delivery stability.
METR, early-2025 study of experienced open-source developers: 16 developers took 19 percent longer on 246 tasks when using AI tools, while believing afterwards they had been 20 percent faster.