DEV Community

Build vs buy for industrial controllers: the common mistake I see

After 13 years of industrial projects, I can usually tell early how a build-vs-buy decision will go. And it tends to go wrong the same way. The engineers want to build because building is the interesting work. Finance wants to buy, because buying looks cheaper this quarter. Both sides argue from instinct. Instinct is not a decision. The decision needs numbers. And the number people start with is almost always the wrong one.

That number is the per-unit cost. Here is why it is a trap.

A real example

A few years ago, a UK-based energy aggregator came to us. They ran distributed energy systems across thousands of field sites. They used off-the-shelf industrial PCs with GSM modules, at about ยฃ1,200 per installation. With around 3,000 installations planned, that is ยฃ3.6M of hardware that does not scale.

The obvious move was to build custom hardware and push the unit cost down. And custom hardware did win on unit cost. Our conceptual custom design came in at around ยฃ140 per unit. If per-unit cost were the whole story, we would have built it. But it is not the whole story.

Custom hardware also meant:

  • 12 to 18 months of development
  • Real upfront cost
  • Certification work
  • The constant risk of a board re-spin

The off-the-shelf option we chose was a Siemens SIMATIC IOT2020 running Yocto Linux, at about ยฃ260 per unit. On the spreadsheet, that ยฃ120 premium looked like a loss. What it actually bought was no certification overhead, no re-spins, no timeline risk, and immediate availability. For a project that needed to deploy soon and at scale, that was the cheap option, not the expensive one.

The thing that decided it never shows up in a per-unit comparison. The existing software moved onto the IOT2020 with no major changes. We adapted the Yocto environment, added Modbus for the external heating and industrial devices, and added Perl runtime support so their existing scripts kept running. Keeping the software platform intact removed a whole class of cost and risk that a per-unit number cannot see.

The final numbers

  • Unit cost dropped from about ยฃ1,200 to ยฃ260
  • Hardware cost across 3,000 units dropped from about ยฃ3.6M to ยฃ780K
  • The engineering to get there was around โ‚ฌ20,000

And the cheaper-per-unit option, custom hardware, would have been the wrong call.

The four comparisons that matter

So when someone asks me build or buy, I do not answer with an opinion. I answer with four comparisons, and you have to do all four honestly:

  1. Total cost at your real volume, not per unit.
  2. Timeline, and what a delay actually costs you.
  3. Risk, which means re-spins, certification, and supply.
  4. What you get to keep, because keeping your existing software is often worth more than a cheaper board.

How we handle it at ARS

At ARS we make this call at the conceptual-design gate of PrecisionPath 7โ„ข, our seven-gate process. And we treat it as a real gate. We design the custom option far enough to cost it properly. We measure the off-the-shelf options against the same yardstick. Then we hand over a side-by-side comparison, not a recommendation dressed up as one.

The teams that get this wrong skip the gate. They commit to building, or to buying, before the work that would have told them which one was right. A โ‚ฌ20,000 feasibility study is cheap insurance against picking the wrong architecture for the life of the product. I have watched the alternative too many times.

If you are facing a build-vs-buy decision and want it answered with numbers, not instinct, send me a message. No sales pitch, just the math.

Comments

No comments yet. Start the discussion.