Are you still just a hardware company when software has become much easier to build?

You cannot copy a hardware company overnight. The software around it is getting easier to build. That changes which software you can still afford to keep at a distance.

Bart van der Meeren

April 4, 2026

7 min read

AI Strategy#AI#Hardware#Industrial#BuildVsBuy#SystemsOfAction

A lot of hardware companies still operate with an old but logical split:

We build the physical product.
We buy the software around it.

For a long time, that was a sensible choice.

Not because software did not matter, but because building software was expensive, slow, and specialized work. If it was not your core competence, buying it was often simply the rational move. Especially when your real differentiation lived in the machine, device, or installation itself.

But something fundamental has changed.

You still cannot copy a hardware company that easily.
The software layer around it is getting much easier to build.

And that is where the strategic logic starts to shift.

What has changed is not the hardware. It is the buildability of software.

Building a hardware company is still hard.

You are dealing with production, supply chains, quality control, certification, margin pressure, physical distribution, service, capital intensity, and often much longer development cycles. You do not replicate that overnight.

Software is a different story.

Because of modern tooling, better cloud infrastructure, and more AI-assisted development, including AI agents that can accelerate a large part of execution work, the threshold for building, testing, and adapting software has dropped sharply. Not to zero. But far enough to force a fresh look at old organizational choices.

That leads to the core question for me:

If software around your product has become much easier to build than it used to be, why would you still keep that layer structurally far away from your own business?

Not all software, of course. But the software that directly affects how your product is used, maintained, supported, and improved.

More and more of the difference sits in the layer around the product

That does not mean hardware companies suddenly need to become software companies in a cultural sense.

But I do think many hardware companies still treat software as something that sits off to the side.

An extra portal.
An extra dashboard.
An extra service interface.
An extra app.

While in practice, that is increasingly where the real difference gets made.

Not just in consumer markets, but especially in B2B and industrial environments.

Think about questions like:

How do you configure a machine?
How quickly do you detect issues?
How do you schedule maintenance?
How well does remote support work?
How does the organization learn from what happens in the field?
How much friction does an operator, technician, or customer experience?

Those are no longer side issues.

That is where usability, uptime, speed, and learning come together. And with them, a growing share of customer value.

You can see that pattern in many places. John Deere is no longer interesting only because of the machine itself, but also because of the digital layer around support, monitoring, and performance. Hilti shows the same thing in a more accessible way: the tool still matters, but the system around management, service, usage, and visibility now carries a large part of the customer value. Caterpillar and Komatsu also show that telematics, maintenance signals, and operational software are becoming less and less secondary.

Those companies did not suddenly become software companies.

They are hardware companies that learned the software layer around their product had become too important to treat as an afterthought.

Distance used to make sense. Now you have to justify it again.

It used to make sense to organize software further away from the core business. Through vendors, outside partners, or generic platforms. Simply because building it yourself was often too expensive, too slow, or too complex.

That argument is much weaker now.

If software is faster to build and adapt, it also becomes more realistic to place it closer to your product team, service organization, and operational reality.

And that means it is worth revisiting what you still outsource out of habit, even though it may already sit close to the way you differentiate.

Not because you need to build everything internally. But because the cost of distance has changed.

If a strategic software layer sits outside your own influence, you lose more than margin. You lose speed.

Every change takes longer. Learning from the field takes longer. Service improvements land later. Your priorities start moving with someone else’s roadmap.

You do not always feel that on day one. But the moment customer expectations shift or you need to improve faster, it becomes obvious.

Not all software is strategic

There is nuance here.

You probably still should not build your own ERP. Or payroll. Finance tooling, standard HR systems, compliance tooling, generic CRM foundations, and commodity infrastructure are still things most companies are better off buying.

That is usually not where you win.

But the software layer close to your product and operation is different.

Think about:

machine or system configuration
operator interfaces
service and maintenance flows
remote diagnostics
dispatch and escalation logic
customer portals
usage dashboards
data logic that turns sensor input into action
AI layers for support, maintenance, or interpretation

That is software that directs work, supports decisions, reduces friction, and increases learning.

And precisely because that layer is now much more accessible to build and adapt, it becomes more strategic to keep it closer to your own business.

The real risk

The risk is not that a hardware company is doing too little software.

The risk is that you still treat software as support work while, in practice, a large share of your differentiation already lives there.

You may still sell hardware, but someone else now controls:

how the workflow runs
how data gets interpreted
how service improves
how quickly changes get shipped
how feedback from the field returns into the operation

That is not just a dependency problem. It is also a speed problem.

And speed matters more once software becomes more buildable.

A practical rule of thumb

If I strip it down, this is the rule I would use:

Buy the software that mainly needs standardization.
Bring the software that makes your product smarter, more usable, and more valuable closer to your own business.

Not because AI solves everything.
Not because it sounds modern.
But because the economics of making software have changed.

And once that changes, your organizational choices need a second look too.

The strategic question that actually matters

Most hardware companies do not need to become software companies in identity.

But I do think many of them need to rethink where software belongs.

Because your hardware company is not easily copied.
The software layer around that hardware is getting much easier to build, improve, and adapt.

So for me, the relevant question is not:

Do we also need to do software?

The more relevant question is:

Which software around our product has become so important that we should no longer organize it with too much distance from ourselves?

If you work in a hardware company and notice that software is becoming more important for service, uptime, or customer value, that is probably a much better strategic conversation than the abstract question of whether you also need to become a software company.

If you want to sharpen that boundary, I would be glad to think it through with you.