When to Build Embedded Systems In-House vs. Partner with an Engineering Team

‍

Let me tell you a short story. A few years ago, a company came to us with what looked like a small problem. They were building an implantable nerve sensing device that talks to an external controller over a proprietary 2.4 GHz link, and their firmware update mechanism was misbehaving in a way that seemed minor. After some updates, a few peripherals became unresponsive, so they wanted a few weeks of help to clean it up. A quick fix, in and out.

What we found instead was a set of obscure firmware issues directly tied to their SDK version. Those issues would have made it impossible to update the devices over the air once they were hermetically sealed.

They were only weeks away from locking the firmware and sealing the investigational units intended for an upcoming early-feasibility clinical study evaluating a truly innovative application. Had they proceeded, every unit already built would have been permanently tied to that SDK version, with no practical way to update it after sealing. The only remedy would have been to scrap the devices: tens of thousands of dollars in materials alone, plus a program delay that is much harder to price.

Every single engineer working on that platform was extremely competent. Their attention was understandably focused on the groundbreaking part of the product, and the firmware update mechanism was a blocker to that work rather than the work itself. The failure was invisible from the surface. It never fully showed up in testing. It was a question nobody knew to ask, and it would have surfaced at the single worst moment in the product's life.

That is the real subject of this post. The choice between building a technical capability in-house and bringing in a partner is usually framed as a cost question. It is actually a question about which mistakes you can afford to discover late, and about what is truly core to your mission.

‍

How to make the decision

‍

Strip away the noise and nearly every one of these decisions comes down to two questions.

Is this core to your product, or is it a necessary distraction? Some engineering work is directly tied to the core value of your company. Therapy generation, a robot's navigation algorithm, the functionality the end user interacts with and ultimately judges the whole product by. Other components and features simply have to exist so that the thing you sell can ship. Your device needs OTA updates and a battery charger. Your engineers bringing up a new platform need HITL test fixtures. Your system bootloader has to be absolutely airtight, as the customer in that story nearly found out the hard way. Both kinds of work are critical, and neglecting either one will sink you. Only the first kind is the sort you cannot fully delegate and need to own.

The second question is just as decisive. Do you have someone on your team who can lead it? Not someone who can write firmware. Someone who can define the architecture, choose the silicon, judge whether a design is manufacturable, and tell you honestly when a plan is not going to work. That person is rare, and if you are not an embedded engineer yourself, they are extremely hard to evaluate in an interview.

Put those two together and the answer usually falls out.

‍

The answer in each case

‍

If the work is not core and you can lead it, buy capacity. Staff augmentation or a scoped project both work. You know what you want, you just need hands, and you should optimize for speed and flexibility. This tends to be the more cost effective option too, because the alternative carries a lot of hidden cost. Headhunting, interviewing, ramp-up, idle time between projects and severance all add to the real price of hiring internally, and none of it is there when you rely on a technical partner.

If the work is not core and you cannot lead it, delegate the whole thing. Own the outcome and the requirements, not the work. This is the cleanest case for a full partnership, and the one where trying to hire is usually the worst option, because you would be building a permanent team for a temporary need.

If the work is core and you can lead it, hire. We will come back to this, because it is the case where a partner is the wrong answer and it deserves to be said plainly.

And then there is the fourth quadrant.

‍

‍

The quadrant nobody wants to be in

‍

Core to the product, and no one internally who can lead it. This is the tough one, and it is where most first-time hardware startups actually live. Full delegation means never really owning your own product. Hiring a team means months you do not have, with the added risk that you cannot reliably tell whether the person you are about to hire is up to the task.

The approach that works is to split the two things you actually need. Hire one strong internal lead who owns the outcome, and partner for the development.

The logic is that one senior hire is a solvable problem. You can take the time to get it right, you can lean on advisors to help you evaluate the candidate (feel free to ask us for help if you want!), and you are betting on one judgment rather than five. That person becomes the owner of the architecture and the decisions, and stays with you after the project ends. Meanwhile the build gets the team capacity it needs from day one, without you having to predict in advance every specialty the project will demand.

In this setup, the internal technical lead has to have the authority and the communication skills to lead the job. If they end up as a coordinator relaying messages, you have added a layer and solved nothing. They need to own the outcome and be able to push back on the partner.

This structure also happens to solve two problems that come up constantly and have nothing to do with engineering. Hiring a proficient technical team takes months, and a bad hire in a small team costs far more than their salary, because the project quietly forms around their gaps and the bill arrives much later. And plenty of companies are told by their board or their investors to keep headcount flat regardless of what the roadmap demands. A partner gives you a team that scales up when the project needs six people and down when it needs two, which is closer to the actual shape of a hardware program than a fixed headcount ever is.

‍

Why embedded punishes the wrong call harder

‍

Everything above would apply to a web application. What makes the kind of work we do different is the gap between when a mistake is made and when it is discovered.

A mistake made in week three of a hardware design project tends to surface in month nine, and the correction is usually not a deploy that can be handled in a couple of clicks. It is a board spin (and those boards may already be sealed inside titanium cans, as our friends from the opening of this post nearly learned). It is a re-certification, a change to a manufacturing line, or in the worst case a field action on units already shipped. The cost of an error is not proportional to how hard it is to fix. It is proportional to how much has been built on top of it. 

Take something as apparently mundane as choosing the MCU. It looks like a technical comparison of datasheets, but it is not. It is a bet on supply chain and lifecycle, on SDK and toolchain maturity, on RTOS compatibility, on the power budget, on the certification stack you will inherit, and on where the vendor's roadmap is going. Most of what you need in order to get it right is not in the datasheet. It comes from having shipped on that silicon before. And the technical leader who is working on the true secret sauce, the very thing that is pushing the boundary of knowledge, should not be the one spending a month acquiring it. That is a necessary distraction.

The same is true across the seams of an embedded program. System architecture. Getting the Zephyr foundation right at the start, when it is still cheap to change. Board manufacturability. Test automation, which almost always gets deferred and almost always should not be. An engineer can be genuinely good and still leave gaps in three of those, because almost no single engineer has depth in all of them. This is what silent failure looks like. The project does not blow up. It gradually becomes more expensive and less certain, and nobody can point to the moment it went wrong.

This is the honest argument for a partner, and it is not just about cost per hour. When you work with a team like ours, you are not hiring an engineer. You are getting access to people who have deep, narrow expertise in Zephyr, embedded Linux, FPGA development, ROS 2, hardware design and medical quality, and a working culture where a problem posted in the morning reaches someone who has already solved it by the afternoon.

‍

When full delegation is the wrong call

‍

Fully delegating is probably not the right call when you are developing a mission critical component, or when it has to be maintained across the whole lifecycle of your system. In that case the better approach is usually for the internal team to own that core development, with an external team extending its reach.

The test is whether you are buying a capability or an outcome. Capabilities you keep. Outcomes you can source. If in three years you will still need this work done every week, and it is the thing that separates your company from your competitors, that competence belongs inside your company, and every month you delay is a month of compounding institutional knowledge you do not own.

‍

What to insist on either way

‍

Whichever model you choose, the project has to survive the people who built it. That means the artifacts are not a deliverable at the end, they are the work: system architecture documentation, schematics and BOM, test plans and automated test suites, a reproducible build environment, CI, and traceability where the regulatory context demands it.

The question to ask a prospective partner is not whether they will hand all of that over. Everyone says yes. The question is where the code lives while the work is happening, and what would break if the engagement ended next month. If those questions have clear, straightforward answers, you have probably found the right partner. If they do not, you have your answer too.

‍