A Shipped Device Is Not a Solved Problem

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

Why shipping a connected product is the start of the hard part, not the end — and how we build for the field. The short version: the day a device leaves the bench it becomes a black box, and the only thing that saves you is having built in visibility before it went out. That's what the open EmbedIQ foundation and our engineer-led build are for.

Shipping a connected product feels like the finish line. The team has been heads-down for months; the units power on, pass their checks, and go out the door. But the moment a device leaves the bench, it leaves the one place you could watch it. Now it's in a customer's home, on a factory floor, at a remote site — and the question that decides whether your product is trusted stops being "does it work here?" and becomes "when one of them misbehaves out there, can you tell why?"

For most teams, honestly, the answer is no. And that's not a failure of engineering effort — it's a failure of visibility, and visibility is decided long before the device ships. This is what we do at Ritzy Lab, and here's how we think about it.

---

1. The bench lies by being watchable

On your desk, every device is one cable away from a debugger. You can pause it, read its memory, watch every line run. That's exactly why the bench is misleading: it gives you a level of visibility you will never have again once the product is in the field. Out there, a device is a black box that either works or doesn't, and when one starts acting up, the evidence you'd need to understand it was usually never recorded in the first place. So a real, reproducible-in-the-field failure becomes a guessing game — swap the unit, hope, wait for it to happen again. The cost isn't just engineering time; it's the trust of the customer watching you shrug.

▸ First principle. A device you can't see is a device you can only hope about.

2. Visibility has to be in the foundation, not added after

The instinct after the first field mystery is to "add some logging next release." But you can't retroactively record what already happened, and bolted-on logging tends to be exactly the code nobody had time to write. So we start from the open EmbedIQ foundation, which is built to record what a device is doing without anyone hand-writing logging around it — and every trace it produces is stamped with which device it came from and which firmware version was running. That last detail matters more than it sounds: in a fleet where units are on different versions, "which build was this?" is half the investigation. When something goes wrong, the story is already there instead of gone. And because EmbedIQ is Apache-2.0, you can read the code and run it yourself before you ever trust us with anything.

▸ First principle. You can't add observability after the mystery reboot — it had to be running before it.

3. Field lessons, in the room before the first unit ships

The reason we design for visibility early isn't theory — it's scar tissue. We've taken 45+ products from idea to production line, which means "how will we know what this thing is doing once it's out in the world?" is a question we raise during design, not one we scramble to answer after a thousand devices are already silent in the field. Hardware to cloud, bench to factory floor: it's one team that has debugged the field, not just the demo, and that experience turns what would be an expensive field surprise into a deliberate design choice made up front.

▸ First principle. The time to design for visibility is before you have a thousand silent devices, not after.

How we work

Ritzy Lab pairs the open EmbedIQ foundation with an engineer-led build, so you ship a connected product you can actually see and trust once it's in the field — and you can verify the foundation before we ever talk. If you have devices out there right now and you're guessing why they fail, that's exactly the conversation we're built for. The links, and the longer story, live on my profile — or DM me.

FAQ

Why isn't shipping a connected device the end of the work?
Because once a device leaves the bench it goes somewhere you can't observe it, and the hard question becomes whether you can diagnose a failure in the field. If visibility wasn't built in before shipping, a field problem becomes guesswork — which is why shipping is the start of the operational phase, not the finish line.

What is device observability, and why build it into the foundation?
Observability is a device recording enough about what it's doing that you can understand its behavior remotely. It has to be part of the foundation because you can't retroactively capture a failure that already happened — the recording had to be running before the problem occurred. EmbedIQ is built to record device activity without hand-written logging, with each trace stamped by device and firmware version.

What does the open EmbedIQ foundation give me?
A proven, reusable device layer with built-in, zero-instrumentation observability, released under Apache-2.0 so you can read and run it before trusting it. It means visibility is designed in from the first boot rather than bolted on after the first field mystery.

How does Ritzy Lab work with a team?
We combine the open EmbedIQ foundation with an engineer-led build, hardware to cloud and bench to factory floor, drawing on 45+ products taken from idea to production line. You can verify the open foundation independently before any engagement begins.

This is how we work at Ritzy Lab. If your devices are in the field and you're guessing why they fail, the longer story and how I work live on my profile. — Ritesh | ritzylab.com