Most of Your Firmware Isn't Your Product

What this is. Opinion + Experience + Fact (35% opinion · 25% experience · 40% fact). Written in collaboration with AI — I discuss, I do not outsource.

Sort any firmware project into two piles: the invisible layer every device needs, and the thin slice that makes yours yours. Most of the code lives in the first pile — and that is the pile you can stop rebuilding. Here is how the split works, why the effort quietly flows to the wrong pile, and how to put it back on your product.

Every firmware project I have shipped ends up looking like two piles of code once you sort it honestly.

The first pile is the invisible layer every device needs to exist at all: bring-up and boot, drivers, the RTOS glue, communications, logging, configuration, updates, fault handling. The second pile is much smaller — the slice that makes this device this device: what it senses, what it decides, and what it does. The old 80/20 rule of thumb fits well enough to be useful: most of the lines are in the first pile, and the reason the product exists is in the second.

Let me walk through why only one of those piles is your product, where the months actually go, and how to design so your time lands on the pile that sets you apart.

---

1. The two piles

Pick any connected product and separate its firmware into "what every device like this needs" and "what only this device does." The first list is remarkably consistent from product to product: a boot and bring-up path, peripheral drivers, an RTOS or scheduler underneath, a communications stack, logging and telemetry, a configuration store, a firmware-update path, and fault and recovery handling. The second list is short and specific: the sensing, the control logic, and the behavior a customer is actually paying for.

The exact ratio varies by product — a sensor node and a medical device sort differently — but the shape holds: the invisible layer is the bulk of the code, and the differentiating slice is the minority of it. That is not a complaint about firmware; it is just the anatomy of it.

▸ First principle. Every device carries a large common layer and a small differentiating one — sorting them is the first step to spending your time well.

2. Only one pile is your product

Both piles ship, and both have to be good. But only the second pile is your product. The sensing and the decisions and the behavior are the reason someone chose your device over the alternative. The invisible layer is necessary — a device with a broken update path or no fault handling is not shippable — yet done well, it looks the same as the invisible layer inside every competitor on the shelf.

That is the quiet trap: the common layer is necessary, so it feels like progress, but it does not differentiate. Two teams can build equally excellent plumbing and arrive at identical undifferentiated results, because that is what "the same for every device" means.

▸ First principle. The code that makes your device different is your product; the rest is necessary, not differentiating.

3. Where the months actually go

Here is the part that is easy to miss until you are living it. The invisible layer is deceptively large. It is board-specific, full of edge cases, and routinely underestimated — the update path alone has to survive power loss, the fault handling has to be right the one time it matters, the driver has a datasheet erratum nobody warned you about. So careful, skilled teams pour real months of good engineering into it.

None of that work is wasted in the sense of being sloppy — it is genuinely necessary. But it lands on the pile that cannot set the product apart. Every hour spent getting the common layer right is an hour not spent on the sensing, the decisions, and the behavior that only your team can build. The schedule quietly tilts toward the part that looks the same as everyone else's.

▸ First principle. Effort on the undifferentiated layer is effort not spent on the product only you can build.

4. The plumbing is a solved shape

The encouraging part is that the invisible layer is not an open research problem. Its shape is well understood, and it is nearly the same across products, which is exactly the condition under which something should be adopted rather than rebuilt. A proven, shared foundation can carry boot, drivers, comms, logging, configuration, updates, and fault handling — and if it is designed above the RTOS, it carries across boards too.

For twenty-plus years I rebuilt this layer product after product, and eventually did the sensible thing: distilled it into a clean, RTOS-agnostic foundation and open-sourced it as EmbedIQ. Its flagship is the piece teams most often ship without and regret in the field: zero-instrumentation observability — every state transition, message, and fault captured automatically as a tamper-evident record, no printf and no developer code, in an open .iqtrace format that doubles as a compliance trail. Around it sit the pieces every device rebuilds anyway — OTA updates, device configuration, state machines, and a telemetry pipeline — all on a shared-nothing Functional-Block architecture where each block owns its state and talks only through typed messages.

Let me keep the boundary honest — EmbedIQ is one way to take that pile off the table, not the only one. A mature in-house platform layer, or a Zephyr-native stack you already trust, gets you to the same place. The point is not the brand; it is that the common layer is a thing to adopt, so your calendar goes to your product.

▸ First principle. What is the same for everyone should be adopted, not rebuilt — so your time goes to what is yours.

5. Sort first, then build

The practical move is to do the sort deliberately, at the start, before the schedule fills up. Take your product and put each piece of firmware in one of two columns:

The invisible layer (adopt)	Your product (build)
Boot, bring-up, board support	What the device senses and measures
Drivers, RTOS glue, comms stack	The decisions it makes on that data
Logging, configuration, updates	The behavior a customer pays for
Fault handling and recovery	The feel and quality that make it yours

Everything in the left column is a candidate to adopt from a shared foundation. Everything in the right column is where your team's hours belong. Do the sort once, honestly, and the plan for the whole project changes: the common layer becomes a decision you make quickly, and the product becomes the thing you actually spend the season building.

▸ First principle. Sort the two piles up front, adopt the common one, and your schedule bends toward the product.

---

Firmware will always be two piles. The invisible layer has to be excellent, and it never differentiates; the smaller slice is the entire reason your device exists. Get the common layer off your plate by adopting a foundation built for it, and the months you would have spent there go where they belong — into the product only your team can build.

Sources

The "80/20" here is the Pareto rule of thumb — an illustrative lens, not a measured statistic about firmware; the exact split varies by product. The common firmware layers named above (boot, drivers, RTOS glue, comms, logging, configuration, OTA, fault handling) are standard across embedded products. EmbedIQ is the open-source, RTOS-agnostic foundation described here for the common layer; the code and links live on my profile.

FAQ

What does "most of your firmware isn't your product" mean?
It means the majority of firmware in a typical device is a common, undifferentiated layer — boot, drivers, RTOS glue, comms, logging, configuration, updates, and fault handling — that nearly every device of its kind needs. Your actual product is the smaller slice on top: what the device senses, decides, and does. Both must be good, but only the smaller slice sets your product apart.

Is the 80/20 split a real statistic?
No. It is the Pareto rule of thumb used as a lens, not a measured figure. The exact ratio varies from product to product; the useful point is the shape — the common layer is the bulk of the code, and the differentiating behavior is the minority of it.

Why do teams spend so much time on the undifferentiated layer?
Because it is genuinely large and full of edge cases — update paths that must survive power loss, fault handling that has to be right the one time it matters, board-specific driver quirks. It is necessary, skilled work. The catch is that it lands on the pile that cannot differentiate the product, so the schedule tilts away from the part only your team can build.

How do I spend more time on the part that differentiates?
Sort your firmware into two columns — the common layer to adopt, and your product to build — at the start of the project. Adopt a proven, RTOS-agnostic foundation for the common layer (for example EmbedIQ, or a trusted in-house or Zephyr-native platform), and reserve your team's hours for the sensing, decisions, and behavior that are yours.

What is EmbedIQ?
EmbedIQ is an open-source, RTOS-agnostic foundation for the common firmware layer — the invisible plumbing every device needs. It gives teams shared-nothing blocks, typed events, single-owner state, and built-in observability so the common layer can be adopted rather than rebuilt, freeing time for the product.

The short version of this is on my LinkedIn. The framework is open source — it's called EmbedIQ — and the architecture, the code, and the links live on my profile.