I keep coming back to the same question, and I suspect I’m not the only one in my industry losing sleep over it: What if we built enterprise software all wrong?
Not wrong in the technical sense. The engineering was sound. The systems work. But consider Microsoft Word for a moment. It’s one of the most feature-rich applications ever created: animations, nested styles, form fields, cross-references and a table of contents generator, all of which most users have never once clicked. If you observe how the overwhelming majority of people actually use the software, they’re typing text. Maybe bolding a heading. That’s it. 99 percent of the capability is invisible and unused.
The pattern goes beyond software. Apple spent considerable engineering effort on the Camera Control button, a dedicated hardware key on the iPhone 16 that lets users adjust zoom, focus and shooting mode without touching the screen. Almost no one uses it. Users open the camera the same way they always did. Reviews were mixed; many found it redundant alongside the on-screen controls they already knew. Barely any other manufacturers copied it. We’re creatures of habit, and we adopt new tools far more readily than we adopt new behaviors.
Excel is the same story: a tool capable of financial modeling sophisticated enough to power investment banks, used by most of the world to track a household budget and produce the occasional bar chart.
I’ve spent enough years in software development to understand how this happened. Each new version needed a reason to exist. Each new feature justified the upgrade price. Complexity became the product, not the solution. And for a long time, the market had no alternative but to accept it. If you needed a spreadsheet, you used Excel. There was nowhere else to go.
That’s no longer true.
How Is AI Reshaping Enterprise Software?
AI coding tools allow individuals to build custom, lightweight software on demand, putting simple subscription-based SaaS products at risk. But enterprise-grade software remains indispensable for regulated industries due to complex maintenance, interoperability and the legal accountability provided by vendor contracts.
Different Pilots for Different Planes
What AI coding tools have done, fundamentally, is democratize building. Not at the enterprise level (I’ll come back to that) but at the level of the individual or small team who simply needs a tool to do five specific things.
Someone who needs a simple tracker for their team’s weekly priorities doesn’t need a project management platform with 50 integrations, a Gantt view and a mobile app. They need a tracker. And today, they can describe that tracker in plain language and have something working by the end of the afternoon.
I think of it like learning to fly. You can, in a couple of weekends, become qualified to pilot a small, ultralight aircraft. No years of training are necessary. In some cases, no medical certificate is required. You simply learn the basics, you practice, and you fly.
That’s genuinely impressive. And for a short hop across familiar terrain, it’s entirely sufficient.
But we shouldn’t confuse that simple ability with being qualified to fly a commercial aircraft carrying 300 passengers across the Atlantic. That level of complexity requires thousands of hours. It requires deep familiarity with systems you will rarely use but absolutely must understand when something goes wrong at 35,000 feet. The gap between ultralight and commercial is not one of degree; it is one of category.
Software is the same. AI has created a generation of ultralight builders, and I mean that with real respect. The ability to generate a useful, functional, personalized tool without formal engineering training is remarkable. It’s also, for a large category of use cases, completely appropriate.
Where Software Gets Complicated
The problem comes when people look at what they’ve built on the weekend and assume it scales to Monday morning in a regulated industry.
Enterprise software carries weight that most people can’t see until it falls on them. Maintenance is the obvious one: Someone always has to look after what has been built. But beneath maintenance sits a more complex set of concerns: versioning, backward compatibility, parallel testing environments and deployment pipelines that protect production systems from untested changes. These things are the engineering discipline that keeps systems running when real customers depend on them.
I’ve seen what happens when they’re absent. Production systems serving paying clients stopped dead, with nobody who could recover them. Data at risk. SLAs being breached. The cost of that recovery, both technical and commercial, was far higher than any license fee would’ve been.
The SaaS Reckoning Is Here
This brings me to what I think is the more consequential shift: What happens to the software industry when the mass market can finally self-generate the tools it actually needs?
My view is that the SaaS market will split, sharply, into two categories.
The first category — commodity tools with no genuine moat, no proprietary data and no integration complexity to create real switching costs — will largely disappear. If a business can describe what they need and generate it in an afternoon, the economics of paying a monthly subscription fee for something over-engineered for their actual requirements simply stop making sense. I would put the probability of this happening for the smaller, feature-light tier of SaaS at around 90 percent.
The second category will not only survive, but it may actually be strengthened. There’s a lesson hiding in plain sight based on what happened with Linux. When the open-source movement emerged in the 1990s, the conventional wisdom was that Microsoft was finished. Free software had arrived, and who would pay for a product that they could have for nothing?
And yet, decades later, enterprises are still paying for Microsoft licenses because the contract gave them something AI-generated software can’t: an accountable party. Someone to call when things break. Someone whose obligations to you are written down and legally enforceable.
Self-generated, self-maintained software removes that accountability entirely. For large organizations in regulated industries, that’s not a trade-off they will accept lightly. They might not accept it at all.
The Question the Software Industry Needs to Answer
But here’s the part I find most unsettling and the most fascinating.
If the mass market can now generate exactly what it needs, personalized to its own requirements, stripped of every feature it was never going to use anyway, then we have to ask a serious question about the last 30 years of software development.
Were we building what people needed? Or were we building what we could charge for in the next version?
I don’t think the answer is entirely comfortable. And I think AI is now in the process of correcting it.
The caveat is interoperability. If every individual and every team generates their own bespoke tool in their own bespoke format, data portability becomes a genuine crisis. In a regulated industry especially, that’s an audit problem: regulators and auditors expect traceable, consistent data, not a patchwork of one-off formats that only the team who built them can read. The value of shared standards is easy to overlook until they are gone.
But that’s a problem to be solved, not a reason to stop asking the question. The simplification is coming. The mass market is going to get the software it actually wanted. The part of our industry that was selling complexity for its own sake should be paying close attention.
