As a budding embedded developer, I’ll admit I had the hubris of knowing that I could design a better system than anything you could buy off-the-shelf. I could write a better comm port driver. A more efficient processing algorithm. I even knew I could write a better text editor.^[1]

Then there was that day I realized I was only one person. Sure, I might be the best designer on the planet, but there was only so much I could do by myself.

I’m starting this column here to set a perspective. Most discussions around Make vs Buy focus on dollars and time-to-market. I’ll do a bit of that as well, but I first want to acknowledge that that’s how business unit managers tend to think about Make vs Buy.

Most embedded engineers I know think of quality first. Depending upon the application, people could get hurt using the systems they design. For them, the Make vs Buy argument has a strong emotional context associated with it. It’s their system, and they are wary to bring in components and software and boards they do not have design control over.

It’s not about being able to blame off-the-shelf components if there’s a failure. It’s about not having the system fail in the first place.

The Trade-Offs

As with all aspects of design, there are trade-offs to consider. Twenty years ago, embedded Make vs Buy decisions focused around single-board computers (SBC). SBCs had a processor, memory and I/O. It was a relatively straightforward calculation. The breakeven point was estimated to be somewhere between 5K and 10K boards. If your volumes were higher, you were better off building your own.

With IoT, the Make vs Buy equation has changed substantially. Consider a typical wireless module:

• Antenna: Antenna design, tuning, and qualification is still considered one of the black magic arts of embedded design.
• Signal integrity: Routing high-frequency signals across a board takes careful design and finesse.
• Protocol: You don’t have to write the wireless stack, but you do have to design your system to access the APIs in an efficient manner if you want a reliable, high-performance system with acceptable latency.
• Security: There are several layers of security to consider: protect the wireless channel, protect the data, protect the code, protect the board interfaces, protect the boot image, protect the cloud database, and protect the user’s identity, to name a few.
• Certification: The module has to be qualified to different wireless specifications, depending upon the country. It also has to meet protocol qualifications if you want the product to carry the logo that says your product is a particular flavor of wireless.
• Re-certification: Change a material part of the wireless subsystem and you might be looking at having to go through the certification and qualification processes all over again.

There’s a lot more on a wireless board than just a processor, memory and I/O. And the above list doesn’t include everything. Security has become one of the more difficult aspects of an embedded system to nail down because it changes so quickly. Security updates need to be made to systems in the field with increasing frequency. Depending upon how you design your wireless subsystem, you might have to re-certify even legacy products every time you need to make a security update.

More Than Just the BOM

For many OEMs, IoT is an opportunity to expand their business but it is not their primary business. They have little to no experience with any of the technologies required to connect their devices to the IoT.

Even if your company does have IoT experience, there’s a lot of expertise embedded on these wireless modules. Certainly, you can design your own, but this is quite different than tapping out your own SBC. There’s more here than one designer can take on, if you want to make it to market before the next rev of the protocol comes out.

There’s also continuing design costs to consider. For example, managing security updates throughout a system is not trivial. And all the time you spend handling updates is time you aren’t spending writing the code you’re really good at – and where you add the most value.

The quality question is still important, even more than with a traditional SBC. There are many moving parts to get right. And because of ongoing concerns like security and changing protocols, a module vendor has to keep investing to support boards that are already in the field. If you go with a module vendor, you need someone you can trust. And you’ll need to pay them for it.

So, we’re back to dollars, as promised. But from this perspective of complexity, expertise, and quality, the Make vs Buy equation looks quite different. It involves much more than just the BOM for components. There’s a value to having a partner take on the burden of understanding some or all of the evolving technologies your product depends upon. There’s also the value of being able to adapt to market changes (i.e., new protocols, new security vulnerabilities) quickly and with confidence.

And then there’s the value of knowing your product is backed by a team of experts who not only know they can write the code better than everyone else, they are the ones writing the code.