Building a medical device when the deadline doesn’t move.
A $10M competition, seven disciplines, roughly six months, and working hardware that showed up April 8 for a May deadline. The team finished top three out of ~330 and won an XPRIZE innovation award, mostly by refusing to wait on anything.
Top 3
Finish, out of ~330 teams worldwide
~6 months
To build what sounded like science fiction
4 weeks
From working hardware to delivered device
The Qualcomm Tricorder XPRIZE asked teams to build something straight out of science fiction: a portable consumer device that could diagnose multiple medical conditions and measure vital signs with no physician in the loop. A $10M purse. Roughly 330 teams worldwide. Which is a wild brief to hand anybody.
Cloud DX, a small Toronto team of doctors, engineers, designers, and programmers, went after it. Getting there meant medical diagnostics, wearable hardware, electrical and mechanical engineering, industrial design, UX, and software, all moving at once and all depending on each other. We had roughly six months to turn that into a working product, on a fraction of the budget the challenge implied.
I led software. That meant the Android user experience, plus the integration between the software, the diagnostic systems, the wearable, and the base-station hardware.
- Competition
- Qualcomm Tricorder XPRIZE · $10M purse
- Team
- Cloud DX, Toronto · doctors, engineers, designers, programmers
- Role
- Software lead · Android UX, integration across diagnostics, wearable, and base station
- Result
- Top-3 finish · XPRIZE innovation award
“You can’t build software for hardware that doesn’t exist. Sequence the work (hardware, then integration, then software) or push the deadline.”
“Treat the uncertainty as part of the architecture. Simulate what’s missing, map the dependencies, reassess priorities as things change, and keep finding a path to the outcome.”
The scope wasn’t getting smaller and the deadline wasn’t moving. There also wasn’t enough time, money, or people to run the project the conventional way, which means sequencing it. Finish the hardware, then integrate, then build the software on top.
That sequence was dead on arrival:
- Working hardware didn’t exist for most of the build. The final hardware arrived April 8, for a May deadline.
- Seven disciplines, and no traditional product lead coordinating them. Nobody was coming to untangle the dependencies.
- Every discipline’s schedule depended on some other discipline’s unfinished work, so everyone had a perfectly good reason to wait.
Follow that last one through. If software waits for hardware, and hardware’s waiting on design, and design’s waiting on answers from diagnostics, the whole chain ends up parked at the door. If I’d started the software when the hardware landed, we’d have been screwed.
So the real problem was how to keep building when the things the software depended on didn’t exist yet.
We treated the uncertainty as part of the architecture, something to design around from day one.
- 01
Build against what doesn’t exist yet
Simulators and stand-in interfaces let software development run at full speed months before real hardware was available. When the hardware finally landed, the software wasn’t starting integration. It was finishing it.
- 02
Make the dependencies visible
A live map across software, electronics, mechanical engineering, diagnostics, and product design showed which delays actually threatened delivery and which ones just felt urgent. Effort went where the constraint was.
- 03
Replace the plan with a loop
With no product lead in the middle, the team ran a very tight communication loop and reassessed priorities every time new information arrived. The objective was to keep finding a path to the outcome.
| The conventional build | This build | |
|---|---|---|
| Software waits on | Finished hardware | Simulators and stand-in interfaces |
| Coordination | A product lead and a master plan | A dependency map and a tight loop |
| Hardware-to-delivery window | Months of integration | Four weeks |
The team delivered a functioning Tricorder, finished among the top three teams in the competition, and took home an XPRIZE award for innovation.
The part I carry forward is what it demonstrated. Too many dependencies, too little time, incomplete information, a deadline that couldn’t be pushed, and the thing got delivered anyway. The industry’s default answer to that setup is to wait for certainty, and that’s mostly nonsense.
The competition, Cloud DX’s top-three finish, and the XPRIZE innovation award are public record. This is Matt’s own history as the team’s software lead, not a client engagement.
Companies get stuck when the dependencies aren’t visible and the priorities aren’t clear. Teams wait on one another, everyone optimizes their own piece, and nobody’s looking at the whole system. The XPRIZE was that same stall on steroids, crushed into six months, and it’s where I learned the approach I’ve used on every engagement since: find the constraint, make the dependencies visible, create alternatives, focus everyone on the outcome, and keep moving.
What would your team ship if waiting weren’t an option?
The Next Version finds where the money is actually stuck (starting with whether your numbers are even real) and names each move, what it’s worth, and who runs it. You keep the roadmap either way.