Building a medical device when the deadline doesn’t move.
A $10M competition, seven disciplines, roughly six months. Working hardware arrived April 8 for a May deadline. The team finished top three out of ~330 and won an XPRIZE innovation award. Not by executing the plan. By refusing to wait.
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 that sounded like science fiction: a portable consumer device capable of diagnosing multiple medical conditions and measuring vital signs, without a physician in the loop. A $10M purse. Roughly 330 teams worldwide.
Getting there meant medical diagnostics, wearable hardware, electrical and mechanical engineering, industrial design, UX, and software, all at once, all depending on one another. Cloud DX, a small Toronto team of doctors, engineers, designers, and programmers, had roughly six months to turn all of it into a working product, on a fraction of the budget the challenge implied.
Matt led software: the Android user experience, plus 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.”
“Uncertainty is part of the architecture. Simulate what’s missing, map the dependencies, reassess priorities continuously, and keep finding a path to the outcome.”
The scope wasn’t getting smaller. The deadline wasn’t moving. And there wasn’t enough time, money, or people to approach the project conventionally, which normally means sequencing: 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.
- There was no traditional product lead coordinating seven disciplines. Nobody was coming to untangle the dependencies.
- Every discipline’s schedule depended on another discipline’s unfinished work. Everyone had a reason to wait.
The hard part wasn’t writing the software. It was figuring out how to keep building when the things the software depended on didn’t exist yet.
Uncertainty got treated as part of the architecture rather than something a better plan could remove.
- 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 only felt urgent. Effort went where the constraint was, not where the noise was.
- 03
Replace the plan with a loop
With no product lead in the middle, the team ran an extremely tight communication loop: priorities reassessed continuously as new information arrived. The objective was never to execute the original plan perfectly. It 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 result worth carrying forward isn’t the trophy. It’s the demonstration: an ambitious outcome with too many dependencies, too little time, incomplete information, and no possibility of pushing the deadline, delivered anyway.
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 rarely get stuck because people aren’t working hard enough. They get stuck because dependencies aren’t visible, priorities aren’t clear, teams are waiting on one another, and everyone is optimizing their own piece with nobody looking at the whole system. The XPRIZE compressed all of that into six months, and it forged the approach every engagement since has used: 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?
An X-Ray 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 map either way.