Two Industries, Two Very Different Problems
A car manufacturer sells you a car. But the sale isn’t really the end — it’s the beginning. What follows is years of maintenance, warranty work, service contracts, spare parts. The car keeps paying the manufacturer back long after it leaves the lot.
Software doesn’t work like that. You don’t get a physical thing. You get access — to something that lives on a server somewhere, invisible and weightless. And because nothing physical changes hands, none of those follow-on revenue streams exist. No wear. No parts. No service calls. Just a login.
That gap — between how manufacturing sustains itself and how software tries to — is at the root of why so many software businesses quietly die.
The Recurring Revenue Myth
For the last twenty years, the software industry convinced itself it had solved this problem. The answer was supposed to be recurring revenue. Subscriptions. SaaS. Monthly fees. Look at Salesforce. Look at Adobe. Look at Microsoft. They turned on the subscription tap and the money flowed. So the logic spread: just add a subscription and the revenue holds.
But that logic is wrong. It’s survivorship bias dressed up as strategy.
The companies that made it work had something most companies don’t. Their software was so embedded in how businesses operated that leaving was genuinely painful — not just inconvenient, but structurally costly. Their customers couldn’t cancel without something real breaking. That’s a very specific set of conditions. Most software doesn’t meet them.
For most companies, subscriptions have to be earned over and over again. Customers churn when budgets tighten. They leave when a cheaper alternative shows up. They cancel because they’re paying for features they’ve never touched. And unlike a factory owner who can’t ignore a broken assembly line, a software customer can just stop. Close the tab. Walk away.
The metrics covered this up for a long time. ARR (Annual Recurring Revenue) charts looked healthy. Venture capital kept the lights on. But underneath, the model was fragile. It wasn’t customers being dragged back by necessity. It was someone having to re-sell the same thing to the same person, every single year.
Why Manufacturing Actually Works
Here’s the part that doesn’t get said clearly enough.
Manufacturing doesn’t sustain itself because salespeople are good. It sustains itself because physics is non-negotiable.
The brake pads wear down. The hydraulic seals fail. The compressor gives out. No customer “decides” to come back for a service — the world makes that decision for them. The refrigerator just stops working. They have no choice.
That’s a completely different commercial position. The customer’s return isn’t driven by a loyalty program or a well-timed email. It’s driven by entropy — the unavoidable fact that physical things break. The manufacturer doesn’t sell the return visit. Physics writes that contract.
Software doesn’t have entropy. A line of code written in 1995, if you preserved its environment, would run exactly the same today. Nothing wears. Nothing degrades. A bug isn’t rust. A deprecated API isn’t a broken fan belt. Whatever dependency a software company builds, it builds by hand — and has to maintain by hand, every single day. That’s why it breaks so easily.
Most Software Isn’t Actually a Product
This is the part that stings a bit. But it’s worth sitting with.
Think about what an ERP system does. Or a CRM. Or a project management tool. These products organize and speed up work that was already happening before they existed. Businesses ran before ERP. Sales teams operated before Salesforce. Projects shipped before Jira. The underlying work didn’t need the software to exist — it just got faster and more manageable with it.
A refrigerator isn’t like that. Before refrigerators, you couldn’t store food the way modern households do. The appliance didn’t speed up a process. It made something possible that wasn’t possible before. Remove the fridge and a whole category of modern life disappears.
Remove the project management tool? Teams move to spreadsheets and email threads. Annoying, sure. But the work continues.
That difference matters more than it seems. Software that’s merely convenient is also optional. And optional things — no matter how useful — generate a weaker commercial dependency. The customer keeps paying as long as they believe it’s worth it. That belief is always one bad renewal conversation away from changing.
Here’s the line that cuts through all the strategy talk: most software that was built and sold as a product was never actually a product. It was a service wearing a product’s clothes.
A manufactured product exists independently of the seller. You buy a hammer. The seller doesn’t need to stay involved for the hammer to keep working. But a SaaS product? Stop paying, and the access disappears. There’s nothing left. You were renting the whole time — just described in the language of ownership.
Founders built these things believing they were building products. They used product language — shipping, launching, iterating. But structurally, commercially, what they built was closer to a service engagement. And services don’t sustain themselves. People do.
The Question Nobody Taught Founders to Ask
Here’s where the damage gets systemic.
When software companies fail, founders usually describe it the same way: bad timing, not enough capital, competition, poor product-market fit. These explanations aren’t wrong. But they’re often symptoms. Under many of them is a simpler failure: the founder never understood, at the start, that they were building something with no built-in reason for customers to come back.
That’s not a failure of intelligence. It’s a failure of knowledge — a specific kind the industry has never really taught.
Founders learn a lot. Engineering teaches you how to build. Business school teaches you how to sell, manage, and raise capital. VCs teach you how to grow fast. Accelerators teach pitching and product-market fit. Pricing consultants will walk you through a dozen revenue frameworks, each one sophisticated and carefully named.
But almost no one teaches the question that determines whether any of it holds long-term.
That question isn’t about pricing. It’s not about growth. It’s this: what in the real world makes it impossible for the customer to walk away?
Not difficult. Not inconvenient. Impossible. The way physics makes it impossible for a factory owner to ignore a seized machine. The kind of dependency you don’t choose — you just have.
You might wonder why no one asks this earlier. The honest answer is that no one teaches that it’s the most important question. So it doesn’t get asked before the first line of code is written. And because it’s never asked, the answer is almost never built in. Companies assume subscriptions handle it, or trust that good customer success work will hold churn down. Which is just solving it like a service problem — because that’s what they’ve actually built, even if no one named it that way.
What Actual Sustainability Would Look Like
If that’s the diagnosis, the direction of the fix is at least conceptually clear.
For software to be truly sustainable — the way a worn-out brake pad is unavoidable — it needs to couple itself to something in the real world that has its own unavoidable entropy. Not just assist that thing. Become structurally load-bearing inside it, the way software embedded in a pacemaker is load-bearing. Not because it’s useful. Because its absence means something real breaks.
Physical assets age. Regulations change on mandatory timelines. Organizations restructure and create new operational realities overnight. Real-world events produce consequences that can’t be ignored. When software isn’t just useful near these forces but is embedded as their custodian — when removing it means something in the world actually stops working — the customer’s return isn’t a sales problem anymore. It’s a necessity.
But this isn’t a technology problem. It’s a design philosophy problem. It means asking, before you build anything, whether what you’re designing is genuinely load-bearing in the world. Or whether it’s just a more expensive, better-looking spreadsheet.
That’s the question the industry has never learned to ask. The gap between how many software businesses fail and how many should fail — if they’d understood this from the start — is the real price of not asking it.
