The Other Side of the Airline Problem

A little while ago, I wrote an article called Building the Plane Is Hard. Running the Airline Is Harder.

And I still think that is true.

Actually, I think it becomes more true the more people talk about AI as if the whole story is just that software is now “easy.” It is not easy. It is faster to make, yes. Easier to get started, yes. Easier to prototype, absolutely. But there is still this strange modern habit of confusing making something with living with it for the next five years.

Those are not the same activity.

One is exciting. The other has meetings.

The point of that earlier article was that AI reduces the effort of creation, but not the burden of operation. It can help you sketch the aircraft faster. It does not suddenly make safety, maintenance, cost control, governance, and reliability disappear in a puff of machine-generated enthusiasm.

But there is another side to this.

Because if you are already dealing with the burden of operation, then maybe this is exactly the time to rethink what you should own.

Maybe, if you are already operating the airline, this is the right moment to start building more of your own planes.

The Old Answer Was Usually: Just Buy It

For a long time, this was the default enterprise answer to almost everything.

Need a system? Buy one. Need a workflow? Buy a platform. Need internal capability? Buy a product that kind of, mostly, approximately does it, and then begin the ancient corporate ritual of trying to make it behave like your business.

And to be fair, this was not stupidity. It was economics.

Building software used to be expensive in all the worst ways. Not just expensive as in salaries, but expensive as in time, delay, uncertainty, coordination, and the lingering suspicion that halfway through the project everyone would discover they were actually building three systems, not one.

So organizations bought software because they did not want the pain of building it.

Which sounds sensible until you notice what happened next.

They would buy the software. Then they would implement it. Then customize it. Then integrate it. Then wrap it in internal process. Then create training around its odd little habits. Then hire consultants to explain why it behaves in ways no human being would naturally expect. Then build side systems around it. Then spend years trying to make this supposedly off-the-shelf product fit the actual shape of the organization.

At some point you have to stop and ask: what exactly did we avoid here?

Because this is the funny thing. Many companies thought they were avoiding complexity. What they were really doing was renting a generic version of it.

The Cost of Production Has Quietly Changed

This is where AI actually matters.

Not in the vague “everything is changing” sense. That sentence has now been stretched beyond useful life. I mean in a very plain economic sense: the cost of producing software has come down.

Not disappeared. Come down.

It now takes less effort to get to a first version. Less effort to explore an idea. Less effort to test whether a system is viable. Less effort to refine, rewrite, document, scaffold, and extend.

There is still a need for judgment. There is still a need for engineers who know what they are doing. There is still architecture, maintenance, security, quality control, and all the boring grown-up things that software eventually demands from you.

But the entry price for serious internal production is no longer what it was.

And that matters, because for many organizations the old blocker was never really philosophical.

It was just the upfront effort.

“Can we build this ourselves?” was often code for: “Do we really want to spend that much money, that much time, and that much organizational energy just to get to something usable?”

Now that equation has changed enough that it is worth revisiting.

The Strange Expense of Generic Software

There is something slightly absurd about how much money organizations are willing to spend to avoid building software.

They will spend on licenses. Then on implementation partners. Then on customization. Then on connectors. Then on migration. Then on governance. Then on change management. Then on internal workarounds for the features that almost fit, but not quite.

And because all of this is spread out over budgets, departments, and phases, it rarely feels like one giant decision. It just feels like the normal cost of “enterprise transformation,” which is one of those phrases people use when everyone has agreed to suffer politely.

But if you zoom out, a lot of these organizations are already paying heavily for software they do not fully control, do not deeply understand, and cannot easily reshape.

That used to be tolerable because the alternative looked heavier.

Now the alternative looks… not light, exactly, but lighter than it used to.

And that changes the mood.

Because if you are going to spend all that energy anyway, there is a very reasonable question hiding in there:

why not spend more of it building something that is actually yours?

Tailored Systems Have a Different Relationship With Reality

Generic tools are built for the average case. That is their job.

The problem is that most serious organizations do not experience themselves as average, and annoyingly, they are often right about that.

Their workflows are weird. Their constraints are weird. Their approval chains are weird. Their customers are weird. Their regulatory environment is weird. Their internal politics are definitely weird.

And so they buy software designed for a broad market, then spend years trying to convince themselves that their differences are edge cases rather than the actual texture of how the business works.

Tailored software does something else.

When it is done well, it grows with the organization instead of constantly asking the organization to trim itself down into something more standard-shaped. It reflects how the business actually operates. It captures institutional knowledge instead of flattening it. It lets software become part of the company’s leverage instead of a recurring negotiation with someone else’s abstraction.

That is especially important for mission-critical systems.

Because the closer a system is to the heart of the business, the more expensive genericity becomes.

A rough edge in a note-taking app is annoying. A rough edge in a core operational system becomes process drag, compliance pain, reporting confusion, or strategic delay.

If You Already Carry the Burden, Ownership Starts to Look Better

This is really the center of the argument.

The previous article said: do not confuse building with operating.

This article says: exactly. And if you are already operating, then ownership deserves a second look.

Because many organizations already carry the real burden whether they build or buy.

They are still accountable for uptime. Still accountable for compliance. Still accountable for access management, cost, security posture, continuity, internal adoption, auditability, and the consequences of failure.

The vendor may provide the product. But when something breaks, or does not fit, or creates risk, the business still owns the problem.

That is why the airline metaphor works for me.

If you are not in the airline business, building planes is a bizarre hobby.

But if you are already running an airline, if the routes, schedules, safety, economics, and passenger experience are already on your shoulders, then deciding to build more of your own planes does not sound grandiose anymore. It sounds like a serious question about leverage.

Not: can we build software?

But: which parts of our business are now too important to leave generic?

That is a much better question.

This Is Not a Romance About Building Everything

To be clear, I am not making the usual mistake here.

This is not a call for every company to become dramatically emotionally attached to building software in-house. Some systems should absolutely be bought. Commodity tools remain commodity tools. You do not need to rediscover the joy of rebuilding things the market already handles perfectly well.

That would not be strategy. That would be a personality issue.

But there is a category of system that sits much closer to the core of the business. The systems that shape how work gets done. How decisions move. How controls are enforced. How knowledge is retained. How teams move faster or slower. How the organization responds when conditions change.

Those systems are different.

And for those systems, AI has changed something important.

Not the need for thinking. Not the need for discipline. Not the need for operational maturity.

It has changed the economics of getting started, and that is enough to reopen the question of ownership.

Maybe the Money Should Move

This may be the part that organizations need to hear most clearly.

A lot of money that used to go into “implementation projects” was really money spent compensating for the gap between generic tools and specific businesses.

That money did not disappear. It just went into adaptation.

And now, thanks to AI, at least some of that same energy can increasingly be redirected into building internal tools and critical systems that belong to the organization itself.

That does not mean every organization should do it. It does mean more organizations now can.

And if they have the technical maturity to maintain what they build, the long-term logic gets pretty interesting.

Because once you own the thing, you stop negotiating with the boundaries of a generic platform. You stop waiting for roadmap alignment. You stop explaining to your teams why the system cannot quite reflect how the business actually works. You stop paying, over and over, for compromise dressed up as standardization.

You still have to think. You still have to operate. You still have to maintain the airline.

But now the planes can be built for your routes.

The Question Feels Different Now

For years, the question was:

Can we afford to build this ourselves?

Now, in at least some cases, the better question is:

Why are we still paying so much not to own this?

That is a different conversation.

A more mature one, I think.

Less dazzled by AI. More interested in the economics of control. Less obsessed with whether something can be generated quickly. More aware of what the business will have to live with for years.

Maybe that is the real change here. Not that AI has made software effortless, because it hasn’t. Not that ownership has become simple, because it hasn’t. But that the old fear - that building your own critical systems would be too slow, too expensive, too heavy to justify — no longer feels as absolute as it once did. And if you are already operating the airline anyway, that should make you look at the planes a little differently.