Shipping a 5-Year-Abandoned IoT Companion Platform to First Paying Customers

LynkD made IoT hardware—security cameras, smart locks, and a specialty time-based access lock for owners of high-value rental assets like cars and second homes. The hardware was good. The companion software was not. Multiple teams over five-plus years had attempted to build a unified software platform that worked across the full hardware stack, and each attempt had stalled out with a buggy, clunky legacy system that customers tolerated but didn't love.

The CEO brought me in as Director of Product to finish what four prior teams hadn't. The pressure was real: customers were asking for the upgrade, the hardware roadmap was being held back by software gaps, and the company's runway was finite.

When I came in, I didn't start by writing tickets. I started by figuring out why every previous attempt had failed. Two patterns showed up immediately.

First, nobody had ever fully scoped what the software was supposed to be. Each prior team had built the piece in front of them—the camera app, the lock controls, the access management module—and bolted them together. There was no unified product architecture, no shared user model, no consistent flow across hardware types. Customers experienced it as three apps pretending to be one.

Second, the development process was structurally broken. Hardware and software developers were on the same team but operating on different cadences and ticket structures. Tickets were getting handed off between hardware and software with no defined gates, no acceptance criteria, and no clear ownership. Critical work was getting dropped at the seams between teams and only surfacing when QA caught a regression weeks later.

The previous teams hadn't failed because the work was hard. They'd failed because the work wasn't actually defined.

I sat with the CEO until I understood the vision well enough to defend it without him in the room. Then I went to the customers—both the legacy users we'd inherited and prospects evaluating us—to understand how they actually used the hardware, where the gaps in their workflow were, and what they wished a software layer would do for them.

With both inputs, I mapped the full software flow for every hardware type onto a single architecture. Then I designed the system end-to-end in Figma—not as wireframes, but as a complete, cohesive product that engineering could build against. For the first time in the project's five-year history, there was a single source of truth for what was being built.

I wrote the SOPs for our development process from scratch. Every ticket started with the PM (whom I coached) writing a clear user story, application requirements, and acceptance criteria. Tickets moved through defined stage gates: PM scoping → engineering assignment (hardware or software) → cross-team handoff if needed → QA acceptance → done. Handoffs between hardware and software developers became formal events with named owners on both sides, not informal pings that got lost.

The throughput change was immediate and measurable. We went from completing 10 story tickets per sprint to completing 20—a 100% increase in team velocity—without adding headcount. The bigger gain, harder to measure, was the drop in tickets that vanished between teams. Critical work stopped slipping through the cracks.

I led a cross-functional team of fourteen—one PM, two QA engineers, ten developers across hardware and software, and one sales lead—through to launch. We onboarded approximately twenty legacy customers from the old system onto the new platform and brought on roughly five net-new customers, establishing LynkD's first software revenue line on top of the existing hardware business.

I want to be honest about how this story ends, because I think the honest version is more useful. We launched. We hit first paying customers. Shortly after launch, the company ran out of runway. The product worked; the business didn't last. That's a real outcome and I'd rather tell it straight than dress it up.

0→1 builder who ships in chaos. The work that mattered most wasn't writing tickets—it was diagnosing why the project had failed four times before, and then fixing the underlying issues (architecture and process) before fixing the symptoms (features). The product reached customers because the system around the product finally worked.