A device ships. It works on the bench, it passes the demo, and six weeks into the field trial units start rebooting — not all of them, not on a schedule, maybe one in twelve every few days. The team adds logging. The logging changes the timing and the reboots move. Eventually someone with an oscilloscope notices the watchdog firing during a specific sensor read, and three weeks later the cause turns out to be a stack that was 200 bytes short of what the deepest interrupt path needed. Nobody wrote bad code. The code was clean, tested, reviewed. It just wasn't written by someone who thinks in bytes of stack and microseconds of interrupt latency.
placeholder
We've been on both sides of this. We hire general software engineers, we hire embedded engineers, and we've watched capable people from the first side of the fence lose months to problems their instincts weren't built for. This article is about where that cost actually lands — not to argue that generalists are bad engineers, but so you can price the gap honestly before you commit to a delivery date.
The gap isn't language. It's the mental model.
Plenty of general software engineers know C and C++ well. That's not the differentiator. The differentiator is what you assume is true while you're writing the code.
Application development trains you to assume an abundant, forgiving environment: memory is effectively unlimited, allocation is free, the OS will preempt fairly, a crash produces a stack trace, and if something is slow you profile it later. Every one of those assumptions is false on a microcontroller with 64 KB of RAM, no MMU, a hard 500-microsecond control loop, and a customer who expects the unit to run for three years on a battery.
So the failures aren't the obvious kind. They're the kind that pass code review:
- A `malloc` inside a function that runs every cycle — fine for a week, then heap fragmentation kills the device with no error message.
- A shared variable updated in an ISR without `volatile` or a memory barrier, which works until the compiler optimisation level changes.
- A mutex taken in an interrupt context, producing a deadlock that reproduces once every few thousand hours.
- Floating-point maths in a control loop on a part with no FPU, quietly costing hundreds of cycles per operation.
- A blocking `printf` over UART left in production code, adding milliseconds of jitter to a loop that needed determinism.
- A driver written against the vendor HAL with no understanding of what the underlying registers do, so when the HAL behaves unexpectedly there's no floor to debug down to.
None of these are exotic. Every embedded engineer has been bitten by all of them and now carries a reflex against them. That reflex is the thing that takes years, and it's what you're actually buying when you hire for domain depth.
Where the cost shows up in the schedule
The hidden cost is rarely a line item. It shows up as a schedule that keeps slipping in the last 20% of the project, which is the most expensive place for a schedule to slip.
Debugging without a stack trace
On the application side, debugging is a software activity. On the embedded side it's often an electrical one. The question "is this a firmware bug or a hardware bug?" cannot be answered from inside the code. You need a logic analyser on the SPI bus, a scope on the power rail, an understanding of what a marginal pull-up looks like, and enough electronics literacy to read the schematic and the datasheet errata. Engineers who haven't built that habit tend to keep looking for the bug in the software because that's the only place they can see. We've seen a fortnight burned on a "race condition" that was a noisy reset line.
Everything that isn't the feature
Product firmware is mostly not the interesting logic. It's the surrounding work that a generalist has never had to build and often doesn't know to estimate:
- A bootloader and a field-update path that cannot brick the device if power drops mid-write — including A/B partitions, rollback, and signature checking.
- Power management: sleep modes, wake sources, and measuring actual current draw rather than trusting the datasheet's typical figures.
- Persistent storage on flash that has erase-block granularity and a finite write endurance, so wear levelling and power-fail atomicity are design problems, not library calls.
- Board bring-up: clock trees, pin multiplexing, linker scripts, memory sections, and the first painful hours of getting anything to blink.
- Production concerns — factory test firmware, calibration data, provisioning secrets, serial numbers.
- Compliance and certification cycles for radio, safety, or EMC, where a firmware change can invalidate a test result you already paid for.
A generalist estimating the project sees the features. The estimate is often reasonable for the features and wildly short for the product. That's the gap that turns a four-month plan into a nine-month one.
The cost of a bad architectural decision
In web work, a wrong choice is usually refactorable. In embedded work, some decisions harden. Pick a part without enough flash headroom and you'll be fighting for kilobytes for the life of the product. Design a message protocol that assumes reliable delivery and you'll rewrite the whole comms layer when you meet real RF. Skip the hardware abstraction boundary and you cannot unit-test anything on a host machine, so your test cycle stays at "flash the board and watch." These decisions get made in week two, by whoever is available, and they price the rest of the project.
When you genuinely don't need embedded specialists
We'd rather tell you this up front than sell you a team you don't need. There are real cases where a strong general software engineer is the right and cheaper call:
- You're on a Linux-class board — a Raspberry Pi, an i.MX, a Jetson — running a full OS with gigabytes of RAM and no hard real-time requirement. This is mostly systems programming, and a good backend engineer will do well.
- Your work is the cloud, mobile app, provisioning portal or data pipeline that sits alongside the device. That's application work and should be staffed as such.
- You're building a proof of concept where the goal is to prove demand, not ship hardware. Use the vendor SDK, accept the mess, and rewrite later — deliberately.
- The firmware is genuinely thin: read a sensor, publish over Wi-Fi, sleep. Plenty of teams ship this successfully with a generalist and a good reference design.
The line to watch is determinism and constraint. The moment you have a hard deadline measured in microseconds, a battery budget, a safety claim, a certification, or a part you cannot easily re-flash in the field — that's when domain depth stops being a nice-to-have and starts being the difference between shipping and not.
The team shape that actually works
The best embedded projects we've seen aren't staffed entirely with embedded engineers. They're staffed with a small hardware-aware core and a wider ring of application people, with a clear contract between them.
Practically, that means one or two engineers who own the hardware boundary — drivers, RTOS configuration, timing, power, bring-up — and a defined API above that line where generalists can be genuinely productive: state machines, business logic, protocol handling, cloud sync, test harnesses. If that abstraction layer is real, most of the codebase becomes testable on a host machine and most of the team stops needing a board on their desk. That's how you get the cost profile of a mixed team without the failure modes.
It also means investing early in things that feel like overhead: hardware-in-the-loop tests in CI, a build that's reproducible on any machine, mock implementations of every driver, and enough instrumentation that a field failure produces something you can read. That infrastructure is where generalist strength pays off enormously — application engineers are usually better at tooling and CI discipline than firmware specialists are. Use that. When we assemble a dedicated engineering team for device work, this split is the first thing we agree on, before any code gets written.
Questions worth asking before you staff the project
Whether you're hiring in-house or evaluating a partner, these tend to separate people who have shipped hardware from people who have written firmware:
- Walk me through the last bug you found with a logic analyser or a scope. What did the signal actually look like?
- How do you size a stack? How would you know if you'd overflowed one in the field?
- What's your update strategy if power fails halfway through a write?
- How do you test firmware without the hardware attached?
- What did you have to change to get through EMC or radio certification?
- Tell me about a time you chose the wrong part and what it cost.
Answers to those questions come from experience, not from reading. You'll know quickly.
The honest summary
Hiring general software engineers for embedded work isn't a mistake — hiring them without a hardware-aware core, and estimating the project as if firmware were application software, is. The cost of that mistake doesn't appear in the first sprint. It appears as a device that mostly works, a reliability bug that no one can reproduce, and a certification date you keep moving. That's the expensive kind of late.
If you're scoping a device project and want a straight opinion on how to staff it — including whether you need specialists at all — get in touch. We'll tell you where the risk actually sits, and you can see the kind of systems work we've delivered on our work. If your roadmap also includes on-device inference or edge intelligence, that's worth planning against your memory and power budget from day one rather than bolting on later, and our AI and ML engineering team can help you sanity-check what will realistically fit on the part you've chosen.
