What drives the cost of custom software now?

Ambiguity and verification difficulty, in that order. Ambiguity is how much of the work is still undecided when the build starts, because every open question has to be closed by someone eventually. Verification difficulty is how hard it is to prove the software is correct, which depends on what being wrong would cost you. The volume of code barely matters any more.

Has AI-generated code made custom software cheaper?

It has made one part of it much cheaper and left the other parts at the same cost. Writing the implementation used to be the largest line item and is now close to the smallest. Deciding exactly what to build, reviewing what came back, and preparing it to run reliably in production did not get cheaper, so the total falls but nowhere near proportionally.

Why is a small, high-stakes feature more expensive than a large, simple one?

Because cost follows the consequence of being wrong, not the line count. A large internal tool where a mistake means someone re-enters a form is cheap to build and cheap to verify. A small pricing or billing rule where a mistake charges customers incorrectly needs specification, tests, review, and reconciliation that can easily outweigh a system fifty times its size.

Should I still ask for a fixed price?

Only for work where the uncertainty has already been removed. A fixed price on genuinely unscoped work forces the supplier to guess, and the supplier protects that guess by adding extra to the price or by cutting quality later. Fixing the price after a paid discovery phase is reasonable, because by then both sides know what is actually being built.

What does a good estimate look like?

A range whose width tells you something, broken down by piece, with the assumptions written next to it. Each piece should show what could push the number up or down, alongside the total. If a supplier gives you one figure for a build that has not been scoped, they are either guessing or adding extra, and a bare number gives you no way to tell which one it is.

Does adding more people to a build still slow it down?

Yes, and the reason has changed. Coordination cost was always the problem, and it is now a larger share of a smaller total, because the part that used to use the extra people is the part that got automated. Adding engineers to a late build mostly adds meetings.

Where should I spend money to lower the total?

On the specification, early. Every decision closed before the build starts is a decision that does not turn into rework, and rework is where budgets actually go. A paid discovery phase that produces a specification detailed enough to build from is usually the best-value spending in the whole project.

Is maintenance still the largest lifetime cost?

Yes. Building is a fraction of what software costs across its life, and that ratio did not improve even though generation made the build itself faster. A system that can be regenerated quickly still has to be understood, monitored, secured, and changed safely by people for years, so a low build cost says nothing about what the software will cost to run.

How do I compare two very different quotes?

Ask each supplier what they are assuming and what they think the riskiest part is. A supplier who names a specific risk has thought about your problem. A supplier whose quote is low because they assumed the easy version of every ambiguity has not, and you will pay the difference later as change requests.

What custom software actually costs: Reveneau

Q: Do integrations still dominate the budget?

More than ever, proportionally, because the code that calls another system is now trivial to generate while everything around that call stayed hard. Handling rate limits, downtime, data that does not match your assumptions, and the change another team releases next quarter still takes real work. A build with five integrations carries five separate sources of surprise, and a generated first draft tends to handle them poorly.

For most of the history of this industry, software was priced by how much of it there was. Not openly, but that is what the estimates followed: more screens, more endpoints, more code, more months. It was never a good measure of value, and it worked mainly because writing the code really was the largest cost.

That assumption is no longer true. When the implementation is generated, the volume of code stops predicting the bill. We have seen a large internal tool cost less than a small billing rule, and the reason is not complexity in any sense a line count would capture. The cost now sits in other parts of the work, and if you are buying software right now it is worth knowing exactly which parts.

The two things that decide the cost

Look at where the money goes in a build today and you find two places.

Ambiguity is how much of the work is still undecided when building starts. This was always expensive, but it used to be one factor among several. Now it is the largest one, because every open question in a specification has to be answered by somebody. If you answer it, you pay for a conversation. If you leave it open, the model answers it with the most plausible answer and does not mention that it did, and you pay to discover the choice later, in production, after other things have been built on top of it.

This difference in cost is the main point. A team once gave us a neat specification for a pricing engine they were confident about. Two weeks in, real customer data showed the rules contradicted each other in cases the specification never imagined. Nobody priced that, because you cannot price what you have not discovered. Today the contradiction shows up as working code that quietly picks one answer and looks finished, where an engineer would once have stopped to ask.

Verification difficulty is how hard it is to prove the software is right, and it depends on one thing: what being wrong would cost you. A large internal tool where a mistake means someone re-enters a form is cheap to check. A small rule that charges a customer's card is not, because it needs a specification precise enough to test against, a test suite that covers the awkward cases, careful review, and often reconciliation that finds mismatches afterwards.

Put those together and you get the result that surprises people. A fifty-thousand-line internal system can cost less than a five-hundred-line pricing change. The cost of a mistake now decides the price, and the size of the code matters less.

What got cheaper, and what did not

It is worth being precise about this, because "AI makes software cheaper" is true in a way that misleads if you plan around it.

Writing the implementation used to be the largest line item in a build. It is now close to the smallest. That is a real and large saving and it is why projects that used to take quarters can take weeks.

Three things did not get cheaper. Deciding exactly what to build still takes the same conversations with the same people. Reviewing what came back takes longer per line than reviewing a colleague's work, for reasons we go through in what good code review looks like when nobody wrote the code. And turning a working first draft into something that keeps working under real use, with its error handling and its monitoring and its security review, costs the same as before.

So the total falls, but by much less than the drop in the cost of writing code. Anyone quoting you a ninety percent reduction is quoting the saving on one line item as though it were the whole invoice.

Integrations still cost more than people expect

Every outside system you connect to adds work you do not control. A payment provider, a CRM, an old internal database: the easy part is calling it, and the easy part now costs almost nothing.

The hard part was never the calling. It is the rate limits, the downtime, the data that does not match your assumptions, and the change the other team releases next quarter that breaks your system. None of that got easier, and as a share of the budget it grew, because the part around it shrank. A build with five integrations still carries five separate sources of surprise, and those surprises are exactly the kind that a generated first draft handles poorly.

Adding people still does not work

The old rule is still true, and the reason is now clearer. Coordination cost was always what made a late project later when you added engineers to it. What has changed is the ratio: the work that used to use extra people is the work that got automated, so the remaining work is disproportionately the coordination-heavy kind. Specification, review, and judgment are hard to split between many people. Adding people to a late build now mostly adds meetings.

Where to spend to lower the total

The cheapest money in a project is spent on the specification, before anything starts.

This is simple arithmetic. Every decision closed before the build begins is a decision that does not turn into rework, and rework is where budgets actually go. When AI writes code fast, a build with missing decisions produces something quickly, which feels like progress, and the cost of the missing decisions arrives all at once later. In the past such a build failed slowly, where everyone could see it.

A paid discovery phase that ends in a specification detailed enough to build from is usually the best-value line in the whole engagement. It is also the honest basis for a fixed price, which brings us to the last point.

Fixed price, and how to read a quote

A fixed price on genuinely unscoped work forces the supplier to guess, and the supplier prices the guess, either by adding extra to the number or by protecting the margin later when the surprises arrive. Neither outcome is good for you. Fixing the price after discovery is a different thing entirely and is often the right choice, because by then both sides know what is being built.

When you are comparing quotes that differ by a large amount, ask each supplier two questions: what are you assuming, and what do you think the riskiest part of this is. A supplier who names a specific risk has thought about your problem. A supplier whose number is low because they quietly assumed the easy reading of every ambiguity has not, and you will pay the difference later as change requests.

One last thing is the same as it always was. Building is a fraction of what software costs across its life. It still has to be understood, monitored, secured, and changed safely by people for years, and a system that can be regenerated in an afternoon is not automatically a system anyone knows how to operate. A quote that ignores the years after launch only estimates what it costs to start.

Sources

Fred Brooks, "The Mythical Man-Month" (adding people to a late software project makes it later, because of coordination cost): https://archive.org/details/mythicalmanmonth0000broo

What custom software actually costs when writing the code is cheap