#48 Build vs Buy: How AI changes enterprise software and the need for local product talent

When AI services make building software cheaper, what happens to the old “build vs buy” decision, and what happens to the need for product and design competence inside the companies that usually just buy software?

A few weeks ago I was in a meeting. The topic was a new procurement system. Purchase requests, approvals, exceptions, audit trails, etc. They were doing what you’re supposed to do. Get quotes from the usual suspects. Compare packages. Check references. Talk about “best practice”. Then, in the middle of the meeting, one of the participants said, why don’t we build it ourselves?

If this would have been last year, I would have just smiled, but this time I didn’t.

When software production gets cheap enough, “build” becomes a realistic option, especially when you already have the data, and you’ll have to do the integrations no matter what you buy.

The software market correction

I know. In the last 20 years it’s been both faster and cheaper to just buy licenses for these kinds of systems, but maybe that is about to change. Just days earlier, the market had wobbled. Late January / early February enterprise software companies lost around $1 trillion in market value, and big names like SAP (~15%), ServiceNow (~10%), Salesforce (~6%), and Workday (~7%) all took hits in what looked like a nervous reaction to how fast AI capability is moving. 

Increased automation, and eventually more agentic workflows, puts pressure on the seat-based pricing model. If more work is done without a human logging in, “pay per user” stops being a clean proxy for value. Vendors won’t disappear, but pricing and leverage will change.

Keep the data, move the workflow

Most enterprise software companies are still strong at what they’re really built for: keeping data safe, consistent, searchable, and traceable. There’s comfort in that, and comfort in having someone accountable when things break.

But the daily work rarely maps neatly to the vendor’s UI. The way decisions are made, how exceptions are handled, the handovers between teams, the local rules nobody wrote down… 

This is where “best practice” tools almost always become “not quite right.” And when a tool is not quite right, people don’t just become inefficient, they build workarounds. They export to Excel. They create side channels. They do the real work somewhere else.

I’m not saying that this shift is about replacing the whole system, at least not in the short run, but it’s likely going to change where the work actually happens.

Integration cost is there either way

Even if you buy the best tool on the market, you still need to connect logins and access, finance, reporting, documents, and whatever internal systems you can’t get rid of. You still need to make data flow. You still need to decide what happens when something doesn’t match, arrives late, or fails.

In many ways, integration is where your real business rules end up living. Once you accept that you already own that layer, it becomes much more rational to also own at least parts of the user interface sitting on top of it. 

Now you can afford a more agile organization

This is where cheaper software production matters. When building becomes faster and more affordable, the “not quite right” tax becomes harder to accept. Not because everyone will rebuild SAP or Workday (they won’t), but because it becomes realistic to quickly build and continuously adapt a front-end to the most important 20% and make sure it specifically fits your organisation as it develops.

A company-specific work hub, continuously tailored to how your organisation actually buys things, is no longer a misallocation of funds, but likely soon a viable option. Employees can start requests, route approvals, and handle exceptions in one place, without ever using the vendor’s often “not quite right” UI. The vendor system stays underneath, keeping the data and compliance in order, but it becomes infrastructure rather than a “complete system” with a user interface.

I don’t think this is a “we ripped out Salesforce” story. It will be more subtle. Fewer seats. More renegotiation. And above all, more workflow moving into local, custom built, tools that sit on top of the core data. The vendor stays, but the center of gravity shifts.

And if you sit in Sweden and buy software from enterprise software vendors, the same shift shows up in budgets. Less money will go to these large companies (who with their +70% gross margins are ripe for disruption anyway) and more to local teams, local partners, and local capability who build and run the custom layer that makes the software fit how you actually work.

The need for local product talent

The cost of producing software is dropping fast. When it becomes cheaper to build and change the workflow layer than to live with “not quite right,” more organisations will build closer to the users and the actual work.

That means the need for strong product and design capability close to the business will increase. Not just product management, but design, analysis, research, development… the skills needed to turn vague goals and fuzzy insights into systems that are optimized for both business and people.

If you lead a company, this is a capability question, not a tool question. The interesting part isn’t necessarily which vendor you pick. It’s whether you have the power to shape and evolve your workflows without waiting for someone else’s roadmap.