I had a call last year with a VP of Engineering at a US industrial equipment maker. He opened with: "We want to outsource our firmware." Ten minutes in, it became clear that what he actually needed was to outsource the Linux BSP, the cloud connectivity layer and the mobile app — and to absolutely not outsource the motor control loop his team had spent six years tuning.
We did the work. But the scope we ended up with looked nothing like what he asked for on that first call.
That gap is the reason I'm writing this. The decision to outsource embedded development is almost never a single yes/no. It's a layer-by-layer decision, and the teams who get it right think about it that way from day one. Here's the framework I use.
Start by separating the layers, not the project
A modern connected device is really five or six separate engineering problems stacked on top of each other:
- Hardware and schematic design
- Board bring-up, bootloader, BSP, drivers
- The core application firmware — your control logic, your algorithms
- Connectivity and protocol stacks (BLE, LoRa, Modbus, MQTT, cellular)
- Cloud ingestion, device management, OTA
- Dashboards, mobile apps, fleet tooling
These layers have wildly different characteristics. The BSP work is well-defined, heavily documented by silicon vendors, and largely the same whether you're building a medical pump or a weighbridge controller. The control logic in the middle is where your competitive advantage lives.
Treating all of that as one monolithic "the firmware" and outsourcing it in a single lump is how projects go sideways. So is refusing to outsource any of it because one layer is sensitive.
Keep it in-house when it's your actual product
Here's my honest rule: if the code encodes something your company knows that competitors don't, keep it.
That usually means:
Your core algorithm or control logic. The calibration curve you derived from ten years of field data. The proprietary signal processing. The safety envelope logic that took three certification cycles to get right. Handing this out isn't just an IP risk — it's a knowledge-transfer cost that nobody prices correctly. Explaining why the loop behaves that way takes longer than writing it did.
Anything under active, rapid iteration tied to customer feedback. If the feature is changing weekly because sales is in the field learning things, the round-trip overhead of an external team will hurt more than the extra capacity helps. Outsourcing works best on work you can specify well enough to leave alone for two weeks.
Regulatory-critical code you'll be maintaining for a decade. You can absolutely bring in a partner who knows IEC 62304 or ISO 26262 and many teams should. But if you're a medical device company and nobody on your payroll can explain your own Class B software to an auditor five years from now, you have a structural problem, not a staffing one.
Anything where the spec lives only in someone's head. This is the most common failure mode I see. A team outsources a module, spends four months in clarification loops, and concludes that outsourcing doesn't work. The outsourcing wasn't the problem. The absent spec was.
Outsource embedded development when the work is deep but not differentiating
The flip side is much larger than most CTOs assume. Good candidates to hand to an embedded software company:
Board bring-up and BSP work. Yocto layers, device tree wrangling, kernel patches, getting a new SoC to boot reliably with the peripherals you need. This is specialised, frustrating, and almost never differentiating. A team that has done it thirty times will finish in a third of the calendar time of a team doing it for the first time — not because they're smarter, but because they've already hit the bugs.
Connectivity and protocol plumbing. BLE stacks, cellular modem integration, MQTT/TLS with certificate provisioning, OTA update pipelines with rollback. There is a known-correct way to do these. Reinventing it is expensive and the failure modes only show up in the field at scale.
The cloud and app layer around the device. Embedded teams are often asked to build the dashboard, the fleet management backend, the provisioning portal. They usually can — badly, and slowly, because it isn't their craft. This is the single easiest layer to hand off with the highest return.
Test automation and hardware-in-the-loop rigs. Nobody ever has time for this internally. It's also the thing that most improves velocity six months in.
Second-product and variant work. Once your platform exists, derivative SKUs, regional variants and certification re-runs are well-specified work with clear acceptance criteria. Ideal to outsource; your senior people should be on the next platform.
Genuine capacity crunches with a hard date. If you have a trade show in five months and a two-person firmware team, no amount of hiring fixes it in time. Hiring an embedded engineer in most Western markets is a 3–6 month exercise before they write a line of useful code.
The costs nobody puts in the spreadsheet
When people compare an internal hire to an outsourced team, they compare hourly rates. That's the least interesting number.
The real costs of outsourcing are integration overhead — code review time, architecture calls, someone on your side owning the relationship. Budget roughly 10–20% of a senior engineer's time to manage an external team properly. If you can't spare that, don't start.
The real costs of keeping it in-house are recruitment lead time, the risk of bus-factor-one on a critical subsystem, and the opportunity cost of your best embedded engineer spending six weeks on a Yocto build instead of the thing customers pay for.
And a cost specific to embedded that people forget entirely: hardware logistics. If your partner doesn't have your board on their desk, everything slows to a crawl. Any serious embedded outsourcing engagement starts with shipping units, JTAG probes, scopes and a plan for lab access. We usually ask for hardware before we ask for the contract to be signed.
A decision test you can run in ten minutes
For each module in your system, ask:
- If a competitor read this code, would it hurt us? If yes — keep it.
- Can I write a two-page spec with clear acceptance criteria? If no — you're not ready to outsource it yet, regardless of who you hire.
- Have three other companies solved this exact problem already? If yes — strong outsourcing candidate.
- Will we still be modifying this weekly in twelve months? If yes — lean in-house.
- Do we have someone internally who can review the output competently? If no — outsource the review too, or don't outsource at all.
The common outcome is a split: your team owns the application layer and the IP, an external embedded software company owns the platform, connectivity, cloud and tooling. That's the arrangement that works most reliably in my experience, and it also happens to be the one that leaves you with an internal team who still understands their own product.
What to look for in a partner
If you do decide to outsource embedded development, filter hard on two things. First, has this team shipped hardware that went into the field and stayed there? Firmware that works on the bench is a different discipline from firmware that survives three years of power cycles, brownouts and field technicians. Second, will they say no to you? A partner who agrees to every scope change without pushing back on schedule or architecture isn't being agreeable — they're setting up a fight you'll have in month five.
Ask for the postmortem, not the portfolio. Any team can show you a slick device photo. Ask what broke in the field and what they changed because of it.
Talk it through with us
We've been building embedded, IoT and Python/AI systems out of Surat since 2012 for clients across the USA, UK, Europe and the Middle East — sometimes as the whole device team, more often as the layer alongside an internal one. If you're weighing this decision, we're happy to go through your stack layer by layer and tell you honestly which parts we think you should keep. Reach us at foogletech.com/contact-us.