FROM THE WORK
Two fast-moving events showed me the value of a rough prototype—and why a good demo is only the beginning.
I have joined teams at two health hackathons: NHS Build with FDP and a health event at HLTH Europe using Lovable. One team reached the final; another placed third after building a prototype in about an hour. Those moments were exciting, but the useful lesson for me was less about the result and more about what a team can make visible when it works together.
A rough prototype gives people something concrete to react to. Instead of debating an abstract idea, a clinician can point to a step that does not fit, a product person can ask what information is needed, and a patient voice can challenge an assumption about how someone will use it.
Speed helps with exploration. It does not show that a product is safe, usable across different settings or ready for a live service. A prototype may rely on fictional data, shortcuts and assumptions that would need much more work before any real use.
The best next step after a demo is usually a better question: who has this problem, how do they manage it now, and what would need to be true for a new approach to help? Then check the workflow, safety, accessibility, data handling and ownership before anyone talks about rollout.
You do not need to be a software developer to contribute. Knowing where a patient or staff member gets stuck is valuable. So is being able to explain the awkward exceptions that a neat demo often leaves out.
I see rapid tools as a way to explore and communicate ideas. They can help a team learn what to build—or discover that a clearer process would solve the problem better.
Explore the Practice Lab →