The logical consequence of the SaaS moat disappearing

The line is not just barroom talk. In early 2026, software stocks shed more than a trillion dollars in market value within days, and analyst firms discussed the thesis in all seriousness under labels like the "SaaS-pocalypse" (Forrester, 2026). So there is a serious observation behind the exaggeration, and it only shows once you ask what the value of a SaaS vendor actually rested on.

For a long time it was the plain ability to map a business process cleanly into software and to run that software reliably. Whoever could do that held an edge others could not catch up on overnight, and that edge was the moat a business model lived off.

That nobody seriously believes software-as-a-service will vanish changes nothing here, because the real question is a different one: what happens to a business whose moat is getting shallow? And it is getting shallow faster than many would like.

What flattens the moat

Turning a business process into working software was expensive and slow for years, and whoever could do it held an edge others could not close overnight. AI as a coding aid flattens exactly that hurdle, and it is long past being a niche tool.

According to the Stack Overflow Developer Survey 2025, 84 percent of developers use or plan to use AI tools, up from 76 percent the year before, and roughly half of them do so daily (Stack Overflow, 2025). Whether that actually makes anyone faster is disputed and depends on the task and the experience, but that is not the point here. What matters is that the ability to write software is no longer a scarce good you can found a business on all by itself.

If mapping a process into software loses its rarity, the question becomes what is left as an edge at all. Four things are usually named as the moat, and it is worth looking at each of them honestly.

Domain knowledge is the edge that gets overestimated the most. Of course a deep understanding of an industry carries real value, but that value is thinning, and on a path most people are walking right now without noticing. That path starts with an everyday annoyance.

Picture the moment where you explain to a language model for the third time how a particular task has to run at your company, because last time it got it wrong in the same spot. At some point you are annoyed enough to look for a fix, and then you cannot avoid a term that is turning up everywhere: the skill. A skill is no magic, just a piece of description that gives an AI agent the context for a concrete task, used exactly in the situation where the task comes up. Anthropic, one of the major vendors, compares it themselves to an onboarding guide for a new hire, in which you capture and share your procedural knowledge (Anthropic, 2025).

What happens to you in the process is the genuinely interesting part. To write a usable skill, you have to describe your own process so clearly that a machine can run it, and that forces you to break it into steps, name the edge cases and make the fuzzy parts sharp. You end up understanding and mastering your process better than before, and that is a real gain. Only not yours alone.

Because the moment your process knowledge is written down, it leaves your head and your company for the first time. It now sits documented, gets handed to a model and runs across someone else systems. Whether and how a vendor reuses such input for training depends on the contract and the settings and is handled differently from vendor to vendor. But the direction is clear: the more naturally companies write their workflows down for the AI, the more process knowledge that was exclusive yesterday moves out of people heads into forms that can be shared, copied and generalised. What is an edge today becomes, over time, more ordinary rather than more rare.

Users count as the second moat, because a customer base once won does not wander off easily. That too holds less far than it used to, because users today are as ready and as able to switch as never before. Data can be exported, alternatives are a click away, and the hurdle of trading one tool for a better one has dropped.

Even the lawmaker is pushing in this direction. The EU Data Act requires providers to make switching between cloud services easier, and from 12 January 2027 switching charges, which include the often dreaded fees for exporting your data, must fall away entirely (Art. 29, Regulation (EU) 2023/2854). Lock-in through high exit costs, long a reliable part of the moat, is thereby being dismantled in law as well.

Capital, finally, was long the moat that enabled everything else, because with enough money you could realise things that stayed out of reach for smaller competitors. In a time where much can be done quickly and cheaply, capital alone is no longer a deep moat either. It still helps, but it no longer protects against imitation as reliably as it once did.

On top of that comes a view that tips the supposed advantage of the big players over entirely. Whoever has built up a lot has to protect that base, and that is exactly what makes them slow, because every new trend has to be weighed against existing customers, running contracts and grown systems. A large company cannot simply abandon a path just because a better one appears, since its running business hangs on the old one. Whoever starts on a greenfield instead, without legacy and without regard for an existing base, is often faster and more nimble, and in a time where the surroundings shift quickly, that nimbleness often weighs more than sheer size.

What mostly remains, then, is your own data, because it arises from real operation and cannot be obtained overnight. Whoever collects the data of their own processes, customers and decisions over years holds something another cannot simply copy. That is the moat that still holds best today, and it is no accident that it sits exactly where a company maps its own reality.

Here lies one of the strongest arguments against the reflexive reach for SaaS. If your own data is the last real moat, then with a bought service you hand that very moat to someone else, and even the best data processing agreement changes little about that, because it governs the use but still leaves the data sitting on foreign systems.

And it is not only about the obvious contents like customer names or revenue, but also about the meta data, which tends to get overlooked. Meta data is the data about your data: who accesses what and when, which events pile up, at what times something happens, which steps run in which order. From this surrounding detail you can often read more about a business than from the contents themselves, because it shows the patterns of how the company really works. Whoever hands a process to a foreign service therefore gives away not only the typed-in values, but also the pattern behind them, and that pattern is exactly what makes up the real edge.

What this means for you as a company

If SaaS is no longer the only alternative, the real question arises: what does it mean for you as a company? The answer is not to reflexively buy the next tool, and it is not to replace every bought service with something home-built either. The answer sits one level deeper, and it sounds more uncomfortable at first than it is.

As a company you have to be able to build your own software and to run it, safely and reliably, for its purpose.

Because only then are you able to change your business processes and to learn to understand them better. As long as a foreign service dictates how a process has to look, you bend your operation to fit the software instead of the software to fit your operation. Whoever can build and run it themselves turns that relationship around, and that is exactly the lever the age of AI makes affordable in the first place.

This ability rests on three legs, and none of them is AI alone. It takes people who bring the enthusiasm to actively shape their own working environment instead of taking it as given. It takes tools like coding agents that let these people become effective and actually build something, rather than just wishing. And it takes the domain knowledge that has grown in IT over decades, because without it something runnable appears quickly, but nothing you could run with a clear conscience.

The blind spot when building it yourself

This is where the trap lurks that you fall into especially easily with AI tools. Because the path to the first running thing has become so short, you quickly think of a product in just two parts: the surface you work with up front, and the logic that stores data in the back. Frontend and backend, that is the mental model most people start with, and as an entry point there is nothing wrong with it.

The problem begins where the prototype turns into something that gets real users, real data and real operation. Then it shows that behind the two imagined parts sits a whole row of further fields that do not vanish just because you did not see them on day one.

Users have to sign in safely, data has to be stored and deleted in line with privacy law, the application has to run reliably, errors have to surface before the customer reports them, and a new release has to be able to go live without risk. These are not extras, but the conditions for "I built something" to turn into "I operate something". This is exactly where the IT knowledge grown over decades is not ballast, but the difference between a prototype and a product customers rely on.

AI takes a lot of the mechanical work in these fields off your hands, but it does not take the responsibility for it. The more a coding agent produces, the more it matters that a human can judge whether what was produced is safe, stable and maintainable. Being effective therefore does not mean giving up the ability, but pairing it with the tool.

How this grows, without a grand plan

This ability does not fall into anyone lap, it grows, and for almost everyone it grows along the same phases. It is not a staged plan you work through from the top, but a movement where each phase prepares the next and what you learn flows back into all the following ones. The first step is small, and the further you get, the larger the space of what even seems possible.

In phase one, the today of many companies, everything runs on third-party software, whether as SaaS or installed locally. The vendor sets the roadmap, and your most important feature request lands, if you are lucky, on the roadmap for Q5. That is a perfectly normal starting point, no failing, and for many things it stays the right choice. This third-party software is not only a corset but also a template, because the vendor collected domain knowledge sits inside it, and whatever you like about it and that suits your operation you can note as a model.

Phase two is the groundwork, and it starts with a harmless question: can a piece of pre- or post-work that runs by hand today be automated? The moment you seriously try, no matter whether with AI or your own software, a blind spot shows quickly. Until now the data was pulled together in people heads, spread across a OneNote list here, a few Excel files there, and plenty of experience and gut knowledge that is written down nowhere. For a human that carries surprisingly far, for a program it does not carry at all.

Right there you understand your own input and output data properly for the first time, because you are forced to pull it out of the heads and the scattered files and pour it into a clear, reliable structure. You learn along the way how AI helps process data, and how much clarity it already brings to describe a workflow precisely enough for a program to run it. This clean data base is unremarkable, but it is the foundation for everything that comes after.

In phase three this clarity pays off. With the now clean data and the better grasp of the workflows you can build interfaces between tools that used to run side by side, and you gain reliability because a program carries out a once-defined step reproducibly. That takes nothing from anyone, on the contrary, it frees people from dull repetition and leaves their heads free for what truly needs judgement.

You do have to know this boundary, though. A program can only decide what was defined beforehand and what the data is there for, and it leaves everything else lying or gets it wrong. A human, by contrast, notices when a case does not fit the pattern, asks a colleague briefly, and the matter is settled. A program does not work that way, which is why the real work in this phase is not the coding but the thinking ahead: making the cases and rules explicit enough that the automation does the right thing and hands everything else cleanly back to a human.

Phase four moves from connecting to changing. Up to here you played the existing tools together more cleverly, now you start replacing individual steps with your own that fit your operation exactly, instead of sticking to the shape a vendor once prescribed. A form that never quite fit, a report someone used to assemble laboriously by hand, an approval that always snagged at the same point, now becomes your own code that maps the workflow the way it really runs at your company.

This is exactly where you learn how software development really works, and not just the writing of code. You notice that real software needs more, such as a version you can roll back to, a way to test changes before they go live, and an idea of what happens when something breaks. With each replaced piece not only your skill grows, but also your sense of what is even possible. Ideas that seemed unthinkable before, because everything depended on the vendor, suddenly become a realistic option. From the user who operates tools, you become someone who shapes tools.

In phase five single replaced steps turn into a whole process running on your own software. That is a jump in quality, not just in quantity, because now real operation hangs on what you built. When a colleague cannot work in the morning because your own application is down, it is no longer a hobby project, but a system people rely on.

With that, operation itself becomes the task, exactly the part that showed up earlier in this article as the often underestimated half. The application has to run reliably, you need backups in case something is lost, you have to notice when an error occurs before the colleague reports it, and the data has to be protected. This operational know-how does not fall into anyone lap, but it grows right here, step by step, because every running process raises the next question by itself. And it is this knowledge that turns a company that builds software into one that can also take responsibility for software.

In phase six the view then often turns outward. Whoever has their own processes safely in hand starts, at some point, to offer their own interfaces to the customer, cut so that they support your own processes instead of bending them to a foreign format. This does not have to happen, and not every company reaches it or wants to, but when it does, the circle closes: your own software now also shapes the edge where the company meets its customers.

Concretely that is a customer portal through which orders come in exactly in the shape your own process needs, an interface over which a partner delivers data directly, or a self-service that helps the customer and reduces your own work at the same time. The difference from a bought standard portal is the cut: instead of bending your own workflow to what a foreign product foresees, you shape the touchpoint so that it plays together with your own process. With that, what started inside becomes an advantage the customer feels, and the circle from pure third-party software to the self-shaped outer edge is closed.

The decisive thing about these phases is the feedback. Each one feeds the learning back, and with every solved piece not only your skill grows, but also your sense of what becomes possible next. Clearer data makes the next integration easier, more operational experience creates the confidence for the bigger step, and so the space of the possible widens not evenly, but with acceleration: the further you get, the more doors each single phase opens. At the centre of this whole movement sits an insight that changes more than any single program, namely that software is not simply there and given, but can be shaped.

What this means in practice

That sounds like a lot, but in everyday life it boils down to a single question you ask anew for each process: does this process set you apart, or does it run at your company like at everyone else? If it runs like everywhere, a bought service is usually the better choice, and you save your energy for what matters. If it sets you apart, distinguishes you from the competition, or you want to learn from its data, then it is the process where the ability to build and run it yourself pays off. No more sorting than that is needed to start.

And you do not have to master the operational fields all at once. They knock one after another, each time your product takes a step further, and in exactly that order you learn them. How to start small without overreaching, we describe in the article Starting small in the age of AI.

The consequence of the SaaS moats disappearing is therefore no grim news, but an invitation. If the ability to build software is no longer the scarce good, then the value shifts to what you use that ability for: your own processes, your own data and the people who want to make both better. That is no replacement for good standard software, but the freedom to decide for yourself where you buy and where you build.

If you want to build this ability in your company without overreaching on the operational fields, we are glad to look at your situation together. We bring the IT knowledge grown over decades and enable your people to build, effectively and safely.