The Free Fighter Jet

It starts with a small request. A second date field on that form. A discount that applies itself for trade customers. Thursday’s report going out on Wednesday.

Whoever you ask can build it in an afternoon now, and with an agent beside them, before lunch. So the answer is yes, the demo lands, and everyone leaves the call pleased. I write some of those quotes and the speed is real. What I’ve stopped being able to un-see is the size of what the yes commits you to.

Imagine someone gives your business a fighter jet. Free, delivered, and it genuinely flies.

You run a small charter operation: two single-engine Cessnas, three pilots, one hangar. The new aircraft outclasses everything you own and, from the moment it lands, it is your biggest operational problem. Nobody on staff can fly it. Maintenance wants skills you don’t have. Parts come from suppliers who have never heard of you, and your runway is four hundred metres short.

The jet is free. The air force is what costs.

That is where most people stop the argument, including me until recently. It’s the wrong place to stop, because the air force is getting cheaper too.

The jet is getting cheaper

Here the sceptics are plainly right. A business used to tolerate an awkward workflow because changing the software cost too much: the custom approval process, the client portal, the internal tool shaped exactly around how the team works. AI is eating that constraint, and a CFO looking at a thirty-thousand-dollar annual software bill can reasonably ask why the company keeps paying it.

Klarna became the case everyone cites, dropping Salesforce’s CRM for its own AI-centred stack. It consolidated the data onto an internal stack built with a graph database rather than replacing SaaS with a language model, and it has since walked back its AI-first customer service and rehired people. ^[2] Asked whether everyone would follow, Sebastian Siemiatkowski said the quiet part: “Will all companies do what Klarna does? I doubt it. On the contrary, much more likely is that we will see fewer SaaS consolidate the market, and they will do what we do and offer it to others.” ^[1] The company held up as proof that AI kills SaaS expects fewer and bigger SaaS vendors selling what it built. A twenty-person accounting firm making the same call takes delivery of the same aircraft without the same air force.

The mechanic is getting cheaper too

There’s an obvious objection to the fighter jet, and it lands. AI will maintain the software as well as write it. Agents already produce tests, update dependencies and chase bugs across repositories, and they’re getting better at all of it.

Google’s 2025 DORA research, drawn from nearly five thousand technology professionals, describes AI as an amplifier of whatever an organisation already is. Higher AI adoption goes with higher delivery throughput, and with higher delivery instability, mediated by whether a team already had testing and fast feedback. Worth knowing that the sign flipped: the 2024 study found AI adoption tracking with lower throughput. ^[3]

So grant the objection its strongest form. Say the mechanic gets sixty per cent cheaper, and maintaining an internal system falls from twenty thousand a year to eight.

Then count the aircraft. Sprawl predates all of this: Okta counted an average of 101 applications across its own 2024 customer base, a population weighted towards companies large enough to buy an identity platform. ^[4] The number matters less than what kind of number it is. Every one of those applications was rented, so every one carried its crew on somebody else’s payroll. Now finance builds three tools, operations builds eight, someone replaces the annoying dashboard and someone else automates the thing that happens every Wednesday. Each is a good idea, which is precisely why the count grows — and each is a system where the crew is yours.

That arithmetic has a break-even, and it’s the most useful number here. A sixty per cent cut in unit cost leaves you worse off the moment your system count more than two-and-a-half times: ten systems becoming fifty costs four hundred thousand against your old two hundred. Unit economics improved dramatically; portfolio economics went backwards. I’ve written before about a company that can suddenly say yes to fifty builds instead of ten — this is what it owns afterwards.

SaaS has a scaling law of its own

The standard defence of SaaS is economies of scale: one security team across thousands of customers, one platform across thousands of tenants. AI discounts some of that, though less than the sceptics think, because the fixed costs are the stubborn part. A SOC 2 audit, a penetration test, a 24/7 on-call rota and a cyber policy do not get cheaper because code does.

Underneath sits something economists have understood since Arrow wrote about learning-by-doing in 1962, and it applies to software in a way that has not been priced. Call it economies of learning.

Two companies run similar software. Company A built its own, hits an unusual permissions bug, and fixes it. It has learned one thing. At a vendor serving ten thousand organisations, customer 217 finds a permissions bug, customer 604 exposes an authentication edge case, customer 4,105 operates in a jurisdiction nobody designed for, and customer 7,421 is attacked through a path the security team has never seen. The vendor folds what it can into one shared product, and customer 7,422 gets the benefit without ever meeting the incident.

“Your system learns from your company. A shared system learns from a market.”

What travels between customers is the vendor’s learning: code, tests, safer defaults, security controls, runbooks. The data stays isolated. The lesson doesn’t.

That advantage has limits. Learning saturates. The ten-thousandth permissions bug teaches less than the hundredth.

But software never stands still. New integrations, regulations, attack techniques and customer behaviour keep opening new failure modes. The learning curve flattens, then the world moves underneath it.

And experience has a cost. Yesterday’s hard-won workaround becomes today’s technical debt. Mature software accumulates wisdom and baggage in the same places.

So the real boundary is simple: the lessons have to travel.

Authentication failures rhyme across companies. So do payment failures, migration failures and common infrastructure problems. One customer breaks it and thousands inherit the fix, though it arrives on the vendor’s schedule and behind a flag.

Other knowledge barely travels at all. If the advantage is how your company makes decisions, ten thousand other customers teach you very little.

Rent where failures rhyme. Build where the failures are yours.

Aviation made the opposite choice

Here is the part that should trouble my own metaphor. Aviation refuses to let this knowledge become a moat. Airworthiness directives, accident investigations, confidential reporting: when an aircraft fails anywhere, the lesson is forced into the open and every operator receives it, because the alternative kills people.

Software went the other way. Your vendor’s ledger of ten thousand failures is private, and the privacy is the moat. Whether it should be is a fair question. That it is, is what you’re buying.

The regulator still keeps a category for small conveniences, covering modifications that “may provide a convenience or function that is not required by operating rules or airworthiness standards applicable to the aircraft’s intended operation” — searchlights, low-light vision equipment for ground observation. Approving one means showing it won’t leave the aircraft noncompliant, and the certificate carries a required disclaimer that the modification “has not been evaluated to check its proper operations for its intended function”. ^[5]

Your second date field is a searchlight. So is the discount rule, the Wednesday report, the approval flow built for one important customer. Each is reasonable on the day it’s asked for, and each joins the permanent history of the system.

Then the person who asked for it leaves. Somewhere in your company right now is a rule nobody can explain — the invoice run skips accounts on hold, and whoever approved that moved on two years ago. An agent will read the rule back to you instantly and tell you nothing about why it exists. That gap is what a build forces you to write down, and the reason ownership keeps a crew even when agents do the work.

The interface goes before the operating model

Soon an employee stops opening the CRM and tells an agent what happened instead, while the CRM keeps holding the authoritative record, the permissions and the audit trail. Per-seat pricing stops making sense when fewer humans open the application, and a system of record nobody opens is a lower-margin business than a product people love. Agents are also excellent at the schema mapping and migration that form the largest switching cost most vendors have. AI eats the SaaS interface a long time before it eats the SaaS operating model, and it thins the vendor from both ends on the way.

Johnny’s verdict

We’re heading for far more custom software. Shared software keeps its advantage wherever operating experience compounds, and somebody sells you the crew either way: as a managed service, a retainer or an integrator on standing hours, the subscription comes back wearing a different uniform. My rules:

• Rent where failures rhyme. Identity, infrastructure, security, anything a regulator specifies. Ten thousand strangers have already found the failures you would have to discover yourself.
• Build where the failures are yours. If the valuable knowledge is how your business decides things, no vendor has learned it on your behalf and no vendor can sell it back to you.
• Run the break-even before the build quote. Systems owned now, systems owned in three years. Past two-and-a-half times, cheap maintenance doesn’t save you.
• Ask the vendor questions they can answer. Not “what have you learned” — nobody can audit that. Ask what share of customers run the current major version, how long a security fix takes to reach the whole base, and what the last four post-mortems said.
• Price the liability. Who carries it when this fails, who signs the SOC 2 your customer’s auditor wants, whose insurance pays. That bill does not fall when code gets cheap, and it decides more build-or-rent calls than architecture does.

We have decades of data on how conventional software ages and almost none on software written mainly by agents. Year five is blank: after five model migrations, fourteen integration changes and three hundred small reasonable requests, nobody can tell you what the fleet costs to fly.

The free fighter jet really is coming, and the mechanic will be cheap. Everyone gets a fleet, and the scarce thing becomes knowing how fleets break. Where failures repeat, ten thousand operators inherit a lesson bought once. Where the failures are uniquely yours, nobody has learned them for you, and those are exactly the systems worth owning. Software keeps getting cheaper. Experience still has to come from somewhere.

You are helping me decide whether to build a piece of software or keep renting it, assuming AI makes both building and maintaining it cheaper. Start with what you already hold: search our past chats and your memory of me for the tools I've considered building and the software my business pays for. If you can't reach that history, ask me for both.

Apply these rules:
1. Assume build and maintenance costs both fall, then ask how many systems we end up owning. Price the portfolio, not the system. Past roughly 2.5x growth in system count, a 60% cut in unit cost leaves us worse off.
2. A vendor's real advantage is accumulated operating experience — the failures, attacks and migrations other customers hit first. Lessons only transfer where failures rhyme across companies.
3. Rent where failures rhyme. Build where the failures are specific to how we decide things.
4. Price the liability: who carries it when this fails, who signs the compliance report, whose insurance pays.

Deliver a build-or-rent verdict per item, the number of systems we'd own in three years, a named owner or explicit gap for each system we already own, and the one duty most likely to sink the build case.

If you can browse the web, read the full essay first — it carries the complete argument and sources: https://thejop.com/essays/the-free-fighter-jet/

Prompt from "The Free Fighter Jet" — Johnny Opinion Press, thejop.com