The economics of AI-cheap software: pricing when code is nearly free

The problem

A price is a claim about scarcity. You charge for the thing that is hard to get, and for two decades in business software the hard-to-get thing was the code — a schema, the workflow logic wrapped around it, the screens, the maintenance. So that is what the invoice was quietly attached to, usually dressed up as a per-seat license: a monthly fee, per human, for access to a specific arrangement of forms and rules a team of engineers spent quarters building.

That claim is now largely false. If an AI can generate the app in an afternoon, the code is no longer the scarce input. The awkward question isn't whether software gets cheaper to build — it does — but what happens to the price when the thing the price was attached to falls to nearly free. You can't keep charging for scarcity that no longer exists. So where does the money go?

We've argued elsewhere that the per-seat model is breaking and that the CRUD app stops being a product. This post is the narrower, more practical question those two leave open: once the code is cheap, what do you actually put on the invoice, and how do you meter it? Value capture, not just value.

Why the seat was always a proxy — and why it fails now

Per-seat pricing was never a claim that a login is worth $50. It was a proxy. Headcount correlated loosely with how much value a customer pulled out of the tool: more people using the CRM usually meant more deals flowing through it, so charging per person was a rough, convenient way to charge more when the customer got more. Nobody believed the seat was the value. It was a meter that happened to track it well enough, and — critically — it hid the vendor's actual cost structure behind a clean human-shaped number.

Two things break that proxy at once. First, the correlation snaps. If an agent or a batch of generated logic is doing the work that ten people used to, headcount stops tracking usage — one logged-in human can drive a workload a hundred seats couldn't have produced last year. Charging per seat now undercharges the heavy automated user and overcharges the small team that just wants a few humans in the tool. Second, the part vendors don't say out loud: adding a seat costs the vendor essentially nothing to produce, and customers increasingly know it. A price defensible only while the buyer doesn't examine the cost underneath is living on borrowed time.

So the proxy has to be replaced with something that tracks value when the code is free. There are three candidates, and each one moves the honesty of the transaction in a different direction.

The three replacements, and what each one exposes

Usage-based pricing charges for what the customer consumes — compute, transitions, storage, egress, API calls. Its great virtue is alignment: the bill goes up when the customer actually leans on the platform, and a customer running nothing pays nothing. Its great discomfort, for both sides, is that it exposes cost that seat pricing hid. A per-seat line item is smooth and predictable; a usage line item makes the customer feel every expensive thing they do, and makes the vendor's marginal cost suddenly legible. Usage pricing only works when the unit is something the customer can see and roughly predict — a meter for compute you can't see is just an anxiety generator. The tension is real and worth naming: the fairest pricing model is also the one that removes the comforting fiction of a flat monthly number.

Outcome-based pricing goes one step further and charges for the result — a resolved support ticket, a closed deal, a completed shipment. It is the purest expression of "pay for value," and when it works it is unarguable: you paid because you got the thing. The problem is attribution. Did the platform resolve that ticket, or did the customer's own process, or the agent the customer configured, or luck? Outcome pricing requires a shared, auditable definition of the outcome that both parties trust, and most outcomes in a real business are produced by a tangle of causes no invoice can cleanly separate. Where the outcome is crisp and mostly attributable, it's a superb model. Where it isn't, it becomes a negotiation about credit that neither side enjoys.

Platform/tier pricing charges for the capacity and the guarantees — a bundle of headroom plus the operational promises that make the platform safe to build on. This is the least fashionable of the three and, for anything mission-critical, often the most honest, because it prices the thing that actually stayed scarce when the code got cheap: not the app, but the assurance that the app will run isolated, audited, and up. The risk is that a flat tier slides back toward being a seat by another name — a fixed number disconnected from value — unless the tier is defined by real capacity and real guarantees rather than by how many humans you let in the door.

None of the three is a clean winner, and the honest answer for most platforms is a blend: a generous free floor so small users pay nothing, metered usage so cost tracks consumption above it, and a bundled tier for the buyers whose real requirement is a guarantee, not a unit count. What all three have in common is that none of them charge for the code. The code is the commodity now. You price the compute, the guarantees, and the accountability — the things that didn't fall to zero.

The misconception worth killing: cheap to build ≠ cheap to run

The seductive error underneath this whole conversation is the assumption that "free to generate" means "free to operate." It does not, and conflating them is how buyers talk themselves into bad trades. Generation got cheap. Running the generated thing safely, keeping one tenant's data away from another's, proving six months later who changed what, keeping an integration alive when a field changes, being someone a regulator can call — none of that got cheap, and some of it got more expensive precisely because there is now ten times as much generated software that needs it.

This is why "I can generate it myself, so why would I pay" is only half a thought. You can generate the app. The bill you were avoiding was never really for the app; it was for the substrate it ran on and the vendor who stood behind it. Cheap-to-build software still runs on infrastructure that costs money and demands trust, and pricing that tells the truth attaches the number there. That's the honest framing of the build-vs-buy-vs-configure decision — the choice was never build-or-rent-the-code; it was who you trust to run it.

Where FastYoke lands

We priced FastYoke around exactly this diagnosis, and it shows up as a split most vendors don't make: apps cost $0. Every first-party app we ship and every app on the marketplace is free — not free-as-in-trial but free-as-in-you-own-it, never metered per app, per install, or per seat. That's the deliberate consequence of believing the code is the commodity. Charging for it would be charging for the part that fell to nearly free.

What you pay for is platform usage above a generous free tier. Stay under the free-tier caps and you pay nothing; go over, and the meter is consumption — transitions, storage, egress — not headcount. Add as many teammates and build as many apps as you like; the bill responds to what you actually run, not to how many people you invited. That's usage pricing in the specific place where the customer can see and predict the unit, which is the only place it's fair.

And for the buyers whose real requirement is a guarantee rather than a unit count, the Enterprise Platform bundle attaches the price to the durable, scarce things directly: region pinning, SSO, dedicated compute, PII encryption at rest, a BAA/HIPAA posture, and an uptime SLA, packaged as one flat number instead of a stack of per-app add-ons. That's platform pricing done deliberately — the tier defined by capacity and operational promises, the stuff that stayed scarce, not by seats. Details are on pricing and enterprise; the point here is the shape, not the digits: the invoice is attached to compute, guarantees, and accountability, and pointedly not to the code.

What to watch out for

If you're a buyer, the trap is treating a low build cost as a low total cost. Read a new pricing model for what it's a proxy for now — a usage meter you can't predict is a budgeting hazard, an outcome price on a fuzzy outcome is a future argument, and a flat tier that's really a seat count in disguise hasn't fixed anything. The right question at procurement is no longer "what does the app cost" but "what am I being metered on, can I predict it, and does it track the value I actually get."

If you're a seller, the discomfort is that every model truer than the seat exposes something the seat concealed — usage reveals your cost, outcomes force you to define and defend attribution, tiers force you to justify the bundle on guarantees rather than on access. That exposure is the price of a model that survives contact with a customer who knows the code was cheap to make. Resist it and you'll spend the next few years defending a per-seat number against a buyer who can generate the underlying app over lunch — not a defensible position. Related: how the sprawl of per-seat licenses accumulated in the first place, and why unwinding it is the actual work.

Where this goes

Pricing is downstream of scarcity, and the scarcity moved. It left the code and settled on the compute that runs it, the guarantees that make it safe to depend on, the data and its history, and the vendor who is on the hook when something breaks. The invoices that make sense in the next decade are the ones honest enough to say so — to charge for the part that's still hard and give away the part that isn't. Cheap code doesn't end the software business. It ends the pretense that the code was ever the thing you were paying for.