Apps as a commodity: if software gets cheap to build, will anyone pay for it?

The problem

Here is the question that quietly worries everyone who builds or buys business software right now: if an AI can generate a working app in an afternoon, is software about to become worthless?

The fear is reasonable. For most of the last two decades, the app was the product. You paid for a customer database with some workflow bolted on, a ticketing tool, an inventory tracker — a specific arrangement of forms, tables, and rules that a team of engineers spent quarters building and that you rented by the seat. If that arrangement can now be described in a paragraph and materialized in minutes, the thing you were paying for looks like it just fell to nearly free. And when the cost of making something collapses, the usual instinct is that its price does too.

We've circled this before from a few angles — what it does to per-seat pricing, and what it does to the app as a product. This post is about the part that actually determines the answer: when the app becomes a commodity, what, if anything, still has value? The short version is that the premise contains a hidden assumption, and once you remove it the worry mostly dissolves. Software is becoming a commodity. "Software" was never only the app.

Commodities don't kill markets — they move the money

Start with the economics, because "commoditized" is doing a lot of work in these conversations and it does not mean "worthless." It means something more specific and more interesting: a good becomes standardized and cheap enough that no single supplier can differentiate on it. That is not the end of a market. It is a relocation of where the money in that market lives.

Every commoditized good in history tells the same story. When transistors got cheap, the profit didn't vanish — it moved up to operating systems, then to cloud platforms, then to the applications on top. When bandwidth got cheap, value moved to what you did with it. Commoditizing one layer reliably makes the adjacent layers more valuable, not less — Clayton Christensen gave this its name in The Innovator's Solution, the "conservation of attractive profits": when one stage of a value chain becomes modular and abundant, attractive profits migrate to the stage next to it that is still scarce.

There's a second effect that cuts against the "worthless" intuition even harder. Making something cheaper to produce usually means the world consumes far more of it, not less — the Jevons paradox, first observed about coal, where "technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource." Cheap apps don't mean fewer apps. They mean an explosion of them — every team, every process, every one-off workflow that was never worth a procurement cycle before is suddenly worth generating. And a world running ten times as many apps needs something it barely needed before: a way to run all of them without any single one becoming a liability.

That is the layer the money moves to. So the real question isn't whether apps get cheap — they do. It's which layer stays scarce when they do.

What stays scarce when apps are free

You can generate an app. You cannot, so far, generate the guarantees that make an app safe to depend on. That is the substrate underneath the app, and it is the part that does not commoditize:

Isolation by construction. When you're running one carefully-built app, keeping one customer's data away from another's is a discipline. When you're running a hundred generated ones, it has to be a structural property — a database per tenant, not a shared table you're trusting every generated query to filter correctly. The more apps you run, the more that guarantee is worth, because the blast radius of getting it wrong scales with the app count.

An audit trail nobody can forge. A generated app can do the right thing; the question a regulator or a customer asks six months later is whether you can prove it did. An append-only event ledger — one that records every state change and is never edited or deleted — is not something a code generator produces as a side effect. It's a property of the system the app runs inside.

A sandbox for logic you didn't write. If AI is writing your business rules, you cannot personally review every line, which means you need to run that logic behind guardrails instead of on trust — evaluated as declarative predicates or inside a WebAssembly host with hard resource caps and no access to the host's network or filesystem. The value of that containment goes up precisely as more of the logic inside it is machine-written.

Data you actually own. A commodity you rent from someone else's cloud is still a dependency on that someone. A single portable binary you can run in your own data center, or fully air-gapped with no outbound network at all, is a different kind of thing — the app on top may be a commodity, but sovereignty over where it runs and where the data lives is not.

Lifecycle correctness. An explicit state machine — where a record can only move along transitions that actually exist — is what stops a generated app from silently reaching a state it was never supposed to. Generation gives you the forms fast; it does not give you the guarantee that the workflow underneath can't be driven off a cliff.

None of these are the app. All of them are what you were actually buying when you bought software that a business could stake its operations on. The app was the visible part. This was the load-bearing part.

"Won't AI commoditize the platform too?"

This is the objection that has to be taken seriously, because if it's right, the whole thesis is wishful. If AI can generate the app, why can't it generate the platform underneath — the isolation, the audit trail, the sandbox — and commoditize that too?

Because the substrate is a guarantees problem, not a code-generation problem, and those are different in kind. Generating more code is exactly what AI is good at. But isolation-by-construction, an unforgeable ledger, and a sandbox that holds under adversarial load are not things you get by writing more lines — they are properties you get by being correct under every case, including the ones nobody thought to prompt for, and by being trusted, which is earned over time and destroyed in one incident. You can generate a plausible-looking audit system in an afternoon. What you cannot generate is the confidence that it will hold the first time it actually matters, or the years of it having held.

And the objection quietly cuts the other way. The more apps AI generates, the more valuable the layer that safely contains them becomes — not less. A world drowning in cheap, machine-written software is a world that needs somewhere trustworthy to run it more than it ever did. Commoditizing the app raises the price of the substrate.

So will anyone pay?

Yes — but the invoice changes.

The line item stops being "a license to use this particular app," because that's the part that fell to nearly free. It becomes "the guarantees that let me run apps at all, and the operator who stands behind them." People will pay for isolation they don't have to get right themselves, for an audit trail they can hand to a regulator without flinching, for the ability to run their operation on infrastructure they control, and for someone accountable when it matters. What they will not pay much for, going forward, is the CRUD app itself — that's a feature now, not a product.

This is also where two other things pick up the thread. The willingness-to-pay that leaves the app doesn't only land on the technical substrate; a large share of it lands on trust and the ongoing relationship, which is its own kind of moat. And how you actually price against a commodity — what the new invoice looks like when the code is nearly free — is a question of its own. This post is about the layer underneath both: the thing that stays scarce.

Where this goes

For buyers, the move is to stop shopping for apps and start shopping for substrates and relationships. The right question at procurement is no longer "does this product do what I need" — increasingly, anything can be made to — but "whose platform do I trust to run a growing pile of generated software safely, and who is accountable when one of them misbehaves." The app is table stakes. The substrate is the decision.

For builders, the move is the mirror image: stop trying to sell the app, because that race is ending, and own the layer the app runs on. The durable business isn't the thousandth generated CRUD tool. It's being the place a business can generate its thousandth CRUD tool and still sleep at night.

Software is becoming a commodity. That was always going to happen, and it's fine. The app was never the thing worth paying for. The system that lets you trust one was — and as apps get cheaper, that's the part that gets more valuable, not less.

Related reading: the app as a feature, not a product, why the next apps are generated, not bought, and what running software on infrastructure you own looks like on on-prem.