Look up the word konsult (consultant) in SAOL, the Swedish Academy’s dictionary, and you’ll find “an expert who takes on special assignments, an expert adviser”. Svensk ordbok is along the same lines: “an advisory specialist within a certain (qualified) field”. Go back even further and the word comes from the Latin consultus, which roughly means learned in the law, or legally wise.
The fun part is that there isn’t a single word about hours. Or about supplying eleven developers to a project that runs for three years.
I think about that quite a lot right now, because a certain question keeps popping up with customers in different versions: “Why should we pay half a million kronor a year for a platform, and on top of that hire an army of developers, when Jeff from IT can build the same thing with Claude Code?” Sometimes it’s said as a joke, sometimes in all seriousness in a steering group. And I think the question is fair, even if the answer isn’t quite what you’d first expect.
My hypothesis is that we are moving away from a world where today's SaaS platforms can invoice hundreds of thousands of kronor a year, where consultancies run million-kronor projects for years on end, and where the customer mostly sits in the back seat, writing specs and paying the invoices. Instead, the power is shifting back to the customer. That is going to hurt the platforms, and quite a few (mainly larger) consultancy companies. But I also believe the consultant will be needed, maybe more than ever - just not in the way we’ve grown used to.
My colleague Anders touched on something similar this spring when he wrote about the SaaSpocalypse, and John has written about how to lead when anyone can build. I want to go one step further than saying “SaaS will survive if the products become truly customizable”. I don’t think that’s enough anymore.
Comfortable for two out of three
If we look at how things have worked over the past 20 years, the roles are pretty clear. The platform owns the product and the roadmap. The consultant knows how to make the product work in your business. And the customer? The customer pays the invoice.
The platform charges by order value, per SKU, per API call or per module (or a combination of all of them, if you’re unlucky) and adds an index increase every year. The consultant charges by the hour, and the more complicated the platform, the more hours. I don’t think anyone has had bad intentions here, but neither of them has exactly had a reason to make things simpler either.
The customer hasn’t had much of a choice. Custom building it yourself has been too expensive and too risky. So you bought standard and adapted the business to the system instead of the other way around. If you wanted to change how, say, a pricing rule or a product flow works at a deeper level, you had to queue up on the vendor’s roadmap, or pay for a customization that then had to be kept alive through every single upgrade.
That worked as long as writing code was expensive. It isn’t anymore.
Vibe coding or AI-assisted development?
Before I go on, I need to untangle two concepts that I think get mixed up all the time.
Vibe coding (a term I still haven’t got used to) is when you describe what you want, take whatever the AI spits out and carry on as long as it seems to work. You don’t read the code and have no idea why it works, or what you’ll do the day it stops working. For a prototype or a small internal tool, that’s perfectly fine. But would I build my order management on it? Hardly.
AI-assisted development is something else entirely. Here you have people who understand what they’re building and who use AI to build it faster. They write specs, review and test, and they own the architecture. The AI may write most of the code, but it’s still a human who provides the judgment and takes responsibility when things blow up.
The tools are often the same, so you can’t tell the difference from the outside. Jeff from IT may well be doing both, and it’s not certain that anyone in management knows which.
My hypothesis is about the latter. Vibe coding doesn’t shift any power anywhere; mostly it creates new problems for important production systems. But when an internal team of five people can deliver what took twenty a few years ago, the math suddenly looks very different.
Jeff can code. But does he know the 30-day rule?
So can Jeff build everything himself? Nope. There are two things AI won’t solve for you, and the first is domain knowledge.
To illustrate domain knowledge in our industry, take something as everyday as a price promotion. When you lower a price, Swedish law (in line with the EU rules on price reductions) requires you to show the lowest price that applied during the previous 30 days. Then the promotion preferably shouldn’t eat up the margin, the discounts need to stack correctly (or not stack at all), a returned promotional item has to be credited with the right amount, and the VAT has to be right even when the customer is sitting in Germany. An AI can write the code for a discount field in a few seconds. But it won’t ask you how you calculate the “previous price”, and it’s not the AI that has to explain itself when the Swedish Consumer Agency comes knocking.
In theory, anyone can vibe-code a promotion engine or an order management system. In practice, it rarely becomes something that supports the business, and sometimes not even something that stays within the law. That’s where the risk simply becomes too great.
And here comes something I think a lot of people miss. When you buy a standard platform, you’re not really buying code. You’re buying someone else’s domain knowledge that happens to be packaged in code. When code becomes more or less free, it’s the domain knowledge that holds the value. The only question is whether you have to buy it wrapped in a license costing half a million a year, or whether there are other ways to get hold of it. (Spoiler: there are, and more on that further down.)
The Wild West
The second thing is architecture, and there I think the need is actually growing.
When everyone can build, everyone will build. If you’re not careful, you’ll soon have twenty or so small apps, scripts and integrations that have sprung up here and there, built by different people with different prompts, rarely with any quality assurance and almost never with anyone who has an overview of the whole. It quickly turns into the Wild West.
Anyone who worked in IT in the 90s probably remembers the Access databases or the Excel macro that in practice held the entire warehouse together, written by someone who left long ago and that nobody dared touch. The difference now is that we can produce black boxes like that a hundred times faster. Anders has written on the same theme about the blast radius, meaning that AI doesn’t just make us more productive, it also means more can break when something goes wrong.
So the good old architecture principles become more important, not less. Which system owns which data? Where does the business logic live? How do the systems talk to each other, and how do you notice that something has broken? And who maintains it all when Jeff has changed jobs? Not exactly sexy questions, but they’re the ones that decide whether you’re building something that lasts for ten years or technical debt that nobody dares touch.
A fairly simple way to avoid a large part of the Wild West is to not start from a blank page. Start instead from an existing framework, perhaps open source, that already has a well-thought-out domain model for orders, prices, inventory and promotions. That gives you conventions and structure for free, and an obvious place for the business logic. It keeps both the developers and the AI on the right track. The AI is also considerably better at code it has seen a thousand times before than at something completely homemade.
The current platforms are in for a tough time
For the platforms, reality is changing. In the past, the customer weighed the license against building it themselves for five million kronor and two years of project time. Now they weigh it against building it themselves for a fraction of that, in a few months, and getting something that fits the business exactly.
A platform that doesn’t let the customer make structural changes to how it works will struggle to justify its price tag. Worst off, I think, is the middle layer: the expensive platforms that, when you scratch the surface a little, are mostly a user interface, a database and a bunch of rules. A bit like a PIM system… That’s exactly the kind of system AI-assisted development is good at building.
Will all platforms disappear? No, of course not. Those that are pure infrastructure, or where the regulations are so complex that nobody wants to take responsibility for them themselves, will probably do just fine. But there will be fewer of them, and they’ll probably be cheaper. Or perhaps these AI-driven changes will give rise to an entirely new kind of platform, quite different from the ones we have today.
Consultants who actually consult
So does the customer no longer need consultants? Yes, they do, but remember the definition from the beginning? Expert adviser. Advisory specialist. That’s exactly what the customer will need, and it’s something completely different from what large parts of the industry have been selling for the past 20 years - arms and legs that can code.
A whole football team of developers, three testers and a project manager who come in, build for you and then stay on to maintain it for years is on its way out. After all, that’s exactly the job AI is taking over.
What the customer will need is specialists. Someone who knows pricing and promotions inside out. Someone who has built order flows between e-commerce, warehouse and finance many times and knows where things usually go wrong. Someone who can help create an architecture that holds up even when half the company starts building things. Consultants who actually consult, simply put. Who sit alongside the customer’s own team, set the guardrails, review and coach, but who don’t take over the project and the maintenance.
For the customer this is good news, but only if you as a customer take on the responsibility that comes with it. Developing, maintaining and running your own systems requires your own product owners, some form of in-house architecture capability and a management team that understands what it actually owns. In 2021 I wrote about insourcing e-commerce development and argued that it was time to take back control. Back then, the objection was usually that it was too expensive to do it yourself. That excuse no longer holds.
Summary in a matrix
If I were to boil the reasoning down to a single picture, it would look something like this:
Back to the 90s, only faster
In a way, this is a journey back in time. Thirty years ago, many companies built their own systems, with their own IT department that knew the business inside out. It was slow and expensive, and the code eventually became legacy that nobody wanted to touch. That’s why the standard systems came along, then SaaS, and then the consultants who were supposed to make everything fit together.
Now the pendulum is swinging back, but at a completely different speed. A change that took a quarter can take a week, and a system that no longer fits can be rebuilt instead of being patched and mended for another ten years.
It’s going to be messy for a while. Some will vibe-code themselves straight into hell, and others will cling to their licenses a little too long. But I think the direction is pretty clear.
Jeff from IT won’t replace the platform on his own. But Jeff with a sensible architecture, and a specialist consultant by his side who knows promotions and the 30-day rule, probably will.
And for the first time in a long while, the customer is back in the driver’s seat. That’s probably going to feel a little unfamiliar for many of us in the industry. Including the customer…
