Most connected products don’t fail because the idea was bad. They fail because the embedded software design was treated like a finishing layer, rather than the thing that turns a circuit into a product anyone can live with.

You see it in the gap between “it works on the bench” and “it works in the world”. In the world, power is unpredictable, signals are noisy, networks disappear, users do odd things, and the unit will sit somewhere for six months before anyone remembers it exists. Embedded software design is what decides whether that reality is a problem… or just part of the plan.

The quiet difference between a prototype and a product

There’s a moment in most builds where the hardware is stable, the first data is coming in, and the temptation is to ship momentum instead of structure. It’s understandable: the pressure is always on features, demos, integration, timelines.

But embedded software design isn’t simply the code that “makes it run”. It’s the set of decisions that determine whether the product behaves consistently when you’re not watching it. Whether it wakes when it should, goes back to sleep when it can, logs what matters, and fails in a way that’s diagnosable rather than mysterious. 

The strongest products tend to share a mindset: they treat embedded software design as the product’s operating philosophy. It defines what the device believes is normal, what it believes is risky, and what it does when it isn’t sure.

What you should really be looking for

If you’re assessing a team, a partner, or even your own approach, try this test: do they talk about outcomes, or only implementation?

Implementation is “we’ll use an RTOS”, “we’ll pick this microcontroller”, “we’ll use MQTT”, “we’ll add OTA”. Outcomes are “this device will run for two years on a battery”, “it will tolerate poor signal without draining itself”, “it will recover from brownouts without corrupting data”, “support can diagnose it remotely in five minutes”.

Good embedded software design is visible as outcomes first, and then (only then) as the technical choices that make them true.

Because the reality is that most connected products don’t need “more clever”. They need more deliberate.

The three signals of mature embedded software design

You can usually spot mature embedded software design without reading a line of code.

The first signal is that the system has a default state, and that default is calm. The device is not constantly doing things just because it can. It sleeps by default, it measures with purpose, it transmits when there’s value, and it behaves like energy is expensive. That’s not an optimisation tactic; it’s a worldview.

The second signal is that failure has been designed, not feared. Not in a dramatic, doom-filled way – just practically. Sensors will misbehave. Packets will drop. Storage will fill. Time will drift. The question isn’t whether thse things happen; it’s what the product does when they do. The strongest embedded software design builds in “safe degradation”: less data, slower reporting, a clean reset path, a clean error state, a breadcrumb trail for diagnosis.

The third signal is that the product tells the truth. Not marketing truth – engineering truth. It can explain itself. It can report its health, its uptime, its reset reasons, its signal quality, its power state history. That’s what turns support from guesswork into process. It’s also what turns field data into a roadmap rather than a post-mortem.

Connectivity isn’t a feature, it’s a tax

A lot of teams treat connectivity like a switch you turn on once the “main functionality” is done. In connected products, connectivity is more like a tax you pay forever: power, airtime, retries, coverage gaps, provisioning, security, updates.

This is where embedded software design quietly makes or breaks commercial viability. If the device behaves like the network is always there, it will spend its life trying (and failing) to be online. If it behaves like the network is a scarce resouce, it will be selective, efficient, and resilient.

When you’re assessing embedded software design for a connected product, look for that philosophy. Are decisions being made around duty cycle, reporting strategy, local processing, and what truly needs to be sent? Or is it “just transmit everything and we’ll optimise later”?

“Optimise later” is usually how you end up paying for batteries, callouts, and support hours that never show up on the original spreadsheet.

Security and updates: a trust decision, not a technical one

Security tends to get discussed in terms of checklists. The more important question is simpler: will this device still be trustworthy in three years?

That’s an embedded software design question. It’s about how you provision devices, how you handle credentials, how you update safely, how you recover from failed updates, and how you avoid creating a situation where the only way to fix something is to physically touch every unit.

A connected product without a realistic plan for updates and recovery isn’t “simpler”. It’s a liability with a delay timer.

The thought that changes everything

Here’s the shift that tends to separate products that scale from products that stumble:

Stop thinking of embessed software design as “writing firmware”, and start thinking of it as “designing behaviour”.

Behaviour is what happens when no one is watching, it’s what your customer experiences as reliability. The support load your operations team experiences and what turns a connected device from “interesting” into “dependable” can also be considered behaviour.

That’s what people should be looking for. Not a specific protocol, not a particular framwork, not a fashionable architecture – those are tools. The thing that matters is whether the embedded software design has been shaped around real outcomes, real constraints, and a realistic view of how the product will live in the field.

At TAD, that’s the lens we use. Embedded software design sits alongside hardware, power budgeting, comms strategy, and the realities of deployment – because a connected product is only as storng as the decisions made in the middle.

Click here to get in touch or here to read more.

‘Engineering Design, Imagine what could exist’

Got a web design question or mobile application need? Our in-house design agency, Bluebrick Studios, has you covered. Check out their site to find out how they can help you achieve your mission.