Our approach¶
What we're working on¶
Most teams automate parts of the stack well enough. Unit tests cover the firmware logic. API tests cover the cloud. The build pipeline runs on every commit. Where things break down is at the boundary, when the full system has to be exercised under conditions that resemble the real world.
That's where the manual effort returns. Someone sets up the bench, walks through the test plan, watches the LEDs, checks the app, restarts the device, and tries again. The work is reasonable in isolation, but it accumulates. It depends on one or two people. It doesn't run on every commit. It's hard to reproduce when something fails in the field.
In conversations with engineering leaders, the pattern shows up the same way across very different products: building automation, smart home devices, industrial sensors and controllers. Different stacks, same workflow gap.
How we're thinking about it¶
Our work focuses on the repetitive effort that accumulates where the system meets the physical world: the script writing, the regression orchestration, the reproducing of failures, the documentation, the rebuilding of fragile fixtures every time the hardware revs. Test engineering itself stays where it belongs, with the people who understand the product.
Three observations shape the work:
System-level validation is a workflow problem, not a tooling gap. Teams have CI. Teams have source control. Teams have test management. The friction sits in the steps between those tools, where someone is still doing things by hand because no one has stitched the workflow together for connected products.
Real hardware matters more than emulation, in the places it matters at all. Simulation has its uses, but the failures that bite teams in the field are usually the ones that depend on actual electrical, timing, and environmental behavior. Any approach that ignores that won't be trusted.
The cost of the problem shows up later than the work. Field defects, delayed launches, support load, RMAs, and app-store ratings all trace back to gaps that were technically visible during development but practically invisible because no one had time to chase them. By the time the bill arrives, the team is reacting, not preventing.
What this costs the business¶
Engineering leaders we've spoken with describe the consequence the same way: release cycles stretch, product launches slip, and the team absorbs the overhead as unplanned work. The cost rarely traces back to a missing test. It's the time spent reproducing one failure, the week lost when a fixture breaks, the field issue that takes two months to diagnose because the conditions can't be recreated in the lab.
For most teams, the real measure isn't headcount saved. It's how often the product can be released with confidence, and how much engineering time those releases consume.
Where we are¶
We're talking to engineering leaders, test engineers, and product managers at companies building connected products to understand how this work actually happens today: what's automated, what's manual, where the friction sits, and what would have to be true for an outside tool to be worth bringing in.
If that conversation sounds useful from your side, we'd like to have it.