Somewhere inside every mature HR system is a rule that handles the case where an employee on parental leave transfers to a team in a different jurisdiction mid-cycle, and now their benefits need to be recalculated under two different sets of rules, without resetting the leave clock. Nobody planned for this on day one. It emerged because it happened to a real employee at a real company, and someone had to figure out what the correct behaviour was. That decision got encoded into the system, and from that point on, every customer on the platform got it for free.

That rule is technically code. It runs on a computer. But the value isn't in the implementation. It's in the judgment. The code is just the delivery mechanism.

This is what software actually is. Not the lines. The judgment. Enterprise software is really a collection of thousands of decisions about how work should be done, built up over years of watching things go wrong. The product is the opinion. The enforcement is the value.

A policy document in a shared drive is a suggestion. Software is a guardrail. It doesn't just say how things should work. It makes it structurally difficult to do them wrong. That requires understanding not just the ideal process but how people actually get around it. That kind of knowledge is hard to come by.

The unbundling

There's a popular thesis right now that goes: AI can write code, therefore anyone can build software, therefore SaaS is dead. The logic is clean if you think software is code. It falls apart once you see that software is process.‍

Proposition 1: Enterprise software bundles process logic and process implementation. AI dramatically lowers the cost of implementation. This unbundles the two.

For decades you couldn't have the opinion without paying for the engineering to encode it. AI removes that floor. The implementation layer stops being a barrier. Feature breadth, codebase maturity, years of accumulated technical investment: these were real moats, and they are eroding. The process logic layer is what remains.

What survives and why

Proposition 2: Process judgment has two layers: the default and the delta. AI makes implementing either one cheap. It does not make knowing either one easier.

The default is the opinionated best practice: here's how a well-run distribution company should handle routing and what to do when things go wrong. The delta is the specific deviation: here's why your company, with its mix of cold-chain and ambient freight across three regulatory zones, needs to do things differently in these particular ways.

Both require judgment. AI can implement whatever you decide. It can't tell you what to decide.

The principles are the easy part. What's hard is the edge cases. The broad strokes of good routing logic aren't hard to sketch. A smart operator could do it in an afternoon. What that operator can't anticipate is the long tail of exceptions that only surface across thousands of deployments. The shipment that crosses a regulatory boundary mid-transit. The driver constraint that interacts with a union rest-period rule nobody thought to check. The acquired depot running a different scheduling system that needs to harmonise without disrupting existing routes. Each of these, once solved, becomes part of the product's knowledge base. That's the real asset. A vibe-coded tool starts at zero on this curve.

The customisation shift

Proposition 3: Cheap implementation means companies will customise more, but only where it differentiates them.

Most companies end up adapting their process to their software, not the other way around. A custom workflow in SAP meant a seven- or eight-figure consulting engagement. Most companies looked at that and decided they weren't special enough to justify it.

AI changes this by an order of magnitude. It doesn't just make existing customisation cheaper. It unlocks customisation that was never attempted because it was never economically rational.

But companies won't customise everything. The selection criterion is competitive differentiation. A logistics company will invest heavily in tailoring its routing and exception handling. That's where it wins or loses. It will accept the opinionated default for HR and accounting. A pharma company will customise its clinical trial workflows. It won't touch its travel and expense system.

Who wins

‍In a previous life, I was part of the team that built Westwing into a public e-commerce company across Europe. We ran multiple warehouses with complex logistics. At one point we brought in specialised consultants to help optimise warehouse operations. They were good. They worked with us to develop significantly better processes and their recommendations were sound.

But translating those process improvements into our tech systems was slow and expensive. In many cases we were constrained by what the software could absorb. So the impact was always smaller than the insight.

The consultants had the opinion. The software had the implementation. The two couldn't talk to each other fast enough. AI changes that. The convergence is happening from two directions at once.

SaaS companies are becoming explicitly consultative

The best SaaS companies have always been implicit process consultancies. Every opinionated default is a recommendation. But most have buried this under a sales motion of "here's our platform, configure it how you like."

That's starting to shift. Some are embracing customisation rather than resisting it. For years, customisation was the enemy. It fragmented the product, created support burden, made upgrades painful. That instinct made sense when implementation was expensive. It makes less sense now. The SaaS companies that are pulling ahead are the ones treating customisation as part of the product, not a problem. The ones still defending the standard configuration are finding their customers have alternatives they didn't have before.

How they deliver this varies. Some are building deep consulting capability internally, with people who know the domain and can actually change the system to fit each customer. Others are becoming platforms with ecosystems of specialist partners who do that work. Either way, the scarce resource is the same: people who can sit with a head of supply chain and say "your process has these specific gaps, here's how we'd redesign it, and here's what we'll change for your situation." Part solutions architect, part domain consultant.

A new type of consultancy is shipping software

The other side of the convergence. Historically, specialist consultancies knew how a process should work but couldn't deliver the implementation. Their output was a slide deck and a set of process maps. They'd define the right workflow, hand it over, and hope the client's IT team built it faithfully. Usually they didn't.

What's emerging now isn't the old-school process guru hiring a developer. It's a new generation of technology-native specialist firms that see process and software as a single integrated system. Founded by people who know a domain deeply and know how to ship, enabled by AI that handles the encoding. These firms don't have a gap between process design and implementation because they never separated the two.

This is specifically about deep domain specialists, not generalist consultancies. McKinsey will use AI to produce better slide decks faster. They will not start shipping software. The convergence is at the specialist end, where process knowledge is hard-won and specific.

Where this converges

SaaS companies move toward consulting. Specialist consultancies move toward software. They meet on the same territory, competing on process credibility and speed of delivery: who understands this domain more deeply, who has seen more edge cases, and who can deliver a working, customised system fastest.

There is a trap in all of this. When customisation becomes cheap, the temptation is to customise everything. But most process customisation introduces complexity, and complexity has ongoing costs that outlast the implementation. Every deviation from the default is a thing that needs to be maintained, understood by new hires, and accounted for when the platform updates. The best operators I've seen don't just optimise processes. They have the judgment to know when a process should be killed entirely rather than improved. The same discipline applies here. Just because you can now encode any process deviation into software doesn't mean you should. The hard part was never the encoding. It's knowing when to stop.

Notes: This framework applies most cleanly to horizontal and vertical SaaS that encodes business processes. It's less relevant for infrastructure software, where the moat is performance, or for creative tools, where it's ecosystem.

An obvious counter-argument: if AI has been trained on all the public documentation, forum posts, and regulatory filings in a domain, doesn't it already have the edge case library? Can't a CTO just ask an LLM to build a routing system and get something good enough? Maybe. But AI trained on public data gives you the consensus solution, not the opinionated one. The best process software doesn't encode what most companies do. It encodes a curated view of what actually works, which is a different thing. And even if AI could generate a perfect implementation of any process, someone still needs to answer the questions upstream: should we deviate from the default at all? Is this process differentiating or commodity? Is the customisation worth the complexity it introduces? That's strategic judgment about your company, not domain knowledge about the process. AI doesn't help with that yet.