Part three of a three-part series on lean versus redundancy in hardware. Part one covered your team. Part two covered your supply chain. This one is about the product itself.
An alarm clock has exactly one job. When it fails, nobody finds out until the meeting's already missed.
That's not a hypothetical. It's what happens when a product is built to do the thing, and nothing else. No backup, no way to check its own work. Just the one path, working exactly as designed, right up until it doesn't.
This one is about the product itself: what an MVP quietly gives up when it strips down to the minimum, and how to decide whether that tradeoff is actually fine.
The MVP Is Right. It's Also Incomplete
Building a minimum viable product is the correct move for most hardware startups. Fewer features means faster to build, faster to ship, faster to find out if anyone wants the thing at all. That logic holds.
What it doesn't automatically account for is what happens when a component fails in the field. Lean thinking optimizes for getting to a working version quickly. It has nothing to say about what your product does the moment something inside it stops working, because "working" was the only case anyone designed for.
"Working" is also doing more heavy lifting in that sentence than most teams give it credit for. Working once, in a demo, is a different bar than working every time. Working for a hundred cycles is a different bar than working for a thousand. Working for three months out of the box is a different bar than working reliably three years in, after the electrolytic capacitors have started to drift and a connector has been mated and unmated a few hundred times. An MVP that clears the first bar on each of those hasn't necessarily cleared the second, and nobody decided which one the product actually needed to hit.
That's a specification question, not an engineering one, and it has to be answered before redundancy or observability decisions make any sense. You can't design the right amount of fault tolerance into a product until you've defined what "working" is supposed to mean for the person using it, and for how long.
That gap is invisible until it isn't. And by the time it shows up, you're not fixing a spreadsheet or a Slack thread. You're looking at a physical unit that's already in a customer's hands.
Redundancy and Observability Are Two Different Decisions
People tend to talk about "redundancy" like it's one idea. It's actually two, and they solve different problems.
Redundant components are extra capacity built in so a single failure doesn't take down the whole system. A chair needs three legs to stand. A fourth is redundancy: if one fails, the chair doesn't fully collapse. A fifth is more of the same, at more cost, for less and less benefit each time. An alarm clock's snooze button is a crude version of this. The alarm firing again five minutes later is a second attempt from a system that assumes the first one might not land.
The cleanest version of this idea isn't in a product at all; it's on a skydiver's back. A main parachute and a reserve are two separate systems built around one non-negotiable requirement: the jumper lands safely regardless of which one deploys. Nobody treats the reserve as optional, and nobody argues that packing two parachutes instead of one is over-engineering. The consequence of the main failing is unacceptable, so the redundancy isn't a design choice up for debate; it's the baseline.
Observability is something else entirely. It's the ability to detect that a failure happened at all. A snooze button doesn't tell you the speaker driver is degrading. A current sensor on that same speaker circuit would. So would a microphone listening for the tone the alarm is supposed to produce, confirming it actually fired instead of assuming it did. On that same jumper's rig, an automatic activation device does the equivalent job: it senses that the main hasn't been deployed by a certain altitude and fires the reserve on its own, because waiting for a human to notice the failure is itself a point of failure.
You can have redundancy without observability, and plenty of MVPs do: extra capacity that quietly compensates for failures nobody ever finds out about, until the day it can't compensate anymore. You can also have observability without redundancy, which at least tells you the truth about a system that has no backup plan. The strongest designs have both. The leanest designs, by definition, are missing at least one.
What Redundancy Actually Costs You
None of this is free, and pretending otherwise is how a lean product turns into a bloated one. A second amplifier is another line on your BOM, another component that can itself fail, and another thing your CM has to source and place. A current sensor adds firmware to write, calibrate, and validate. Extra parts mean extra weight, extra board space, and in a lot of cases, a longer path to certification, since anything added to a safety-relevant circuit can put you back in front of a test lab.
This is why "just add redundancy" is bad advice on its own. It trades one failure mode, the product breaking silently, for a different set of costs: schedule, unit cost, and complexity that your team now has to maintain forever. The right amount of redundancy isn't the maximum you can afford. It's the amount your actual failure consequences justify, and not a component more.
Where the Stakes Get Real
I've worked on emergency devices where this stopped being an academic distinction. A device relying on a single telecommunication path to reach a monitoring center has no fallback if that path drops. A single amplifier or a single AC-DC transformer with no way to flag degradation is a silent failure waiting for the worst possible moment to become a loud one.
The bar moves depending on who's using the product. A consumer IoT gadget failing silently is an annoyance. A robotics system failing silently on a factory floor is a safety incident. A defense or medtech device failing silently can be the reason someone doesn't get help. Same engineering question, three completely different acceptable answers, and no single "best practice" that applies across all three.
In that category of product, the question isn't whether to add redundancy and monitoring. It's which failures are unacceptable to miss, and what it costs to guarantee you don't. An alarm clock that fails silently costs someone a meeting. A device built for someone's safety that fails silently costs something you can't get back.
Hardware Doesn't Get a Patch Cycle
Software has an escape hatch that hardware doesn't. Ship a bug, push an update, move on. A firmware issue on a connected device can sometimes follow that same path.
A missing sensor can't. If the failure-detection hardware was never designed into the board, there's no firmware update that conjures a current sensor or a microphone into existence after the fact. You find out what you left out when the field does, and by then it's a hardware revision and a new production run, not a changelog entry.
That asymmetry is why this decision belongs in the design phase, not the postmortem. Once units ship, the redundancy and observability you didn't build in are gone until the next hardware rev.
A Simple Way to Decide
You don't need a formal risk analysis process to start this conversation, though a regulated product will eventually require one. Three questions get you most of the way there for any given component or subsystem: what happens if this fails, who finds out and how, and what does it cost someone if nobody finds out in time.
If the answer to the first question is "the product stops working and the user notices immediately," you probably don't need redundancy or a sensor to tell you about it; the failure is already self-reporting. If the answer is "the product keeps half-working and nobody would know," that's the case worth building observability into, even on a lean product. If the answer touches safety, a regulatory requirement, or a customer contract, that's the case where redundancy stops being optional and becomes part of the spec, whatever the schedule cost.
Tie It to What Your Customer Actually Needs
None of this means every product needs redundant everything. Plenty of hardware genuinely doesn't. The straightforward, single-path design is sometimes the right call, and adding backup systems or sensors nobody asked for is its own kind of waste. Lean is still the right default.
The failure mode isn't choosing lean. It's never asking the question. Before you decide how much redundancy or failure detection to build in, find out what your customer requirements actually demand. A consumer alarm clock and a commercial safety device don't carry the same bar, and they shouldn't cost the same to build. If you're serving commercial customers, emergency services, or anyone operating under a regulatory requirement, that evaluation isn't optional; it's part of the spec, whether or not anyone wrote it down as one.
Run lean where lean is enough. Just make the call on purpose, before the field makes it for you. If you want your BOM, revisions, and design decisions living in one place instead of scattered across specs and Slack threads, see how it works at oroforge.com.
