Distinguishing Prototype, Demo and Roadmap Features
Being precise about what's built, what's demonstrated and what's planned is a discipline we apply to our own product communication.
Article
Why status labels are load-bearing
It's easy for a product under active development to blur the line between what currently works, what has been demonstrated in a curated way, and what's planned for later. That blurring usually isn't intentional — it happens gradually, as screenshots and demos accumulate faster than the underlying language keeps pace with them. We decided early on to make status explicit everywhere it matters, using a small, consistent set of labels across every surface of the site and product.
Those labels — Working Prototype, Experimental AI POC, Curated Demo Output, AI-Assisted Draft, In Development, Future Roadmap — appear next to the features they describe rather than buried in a single disclaimer page. The goal is that anyone evaluating the product, whether a pharmacist trying the guided demo or a partner reviewing our roadmap, can tell at a glance which category a given screen belongs to.
The difference between a demo and a prototype
A curated demo output is content we've built and arranged specifically to illustrate how a feature is meant to work, often using our synthetic case library, without claiming that every input into that feature would behave identically today. A working prototype, by contrast, is functionality that genuinely runs as described for the range of inputs it's built to handle. Conflating the two is one of the more common ways product communication becomes misleading, even unintentionally, so we treat the distinction as something to actively maintain rather than something readers should have to infer.
Our guided demonstration walks through a curated set of synthetic scenarios for exactly this reason: it lets us show the intended shape of the workflow clearly, while the status badges throughout make clear which parts reflect built functionality today.
Roadmap items stay in the future tense
Anything marked as future roadmap is described using intention language — what we plan to build, and why — rather than being illustrated with a working screen that implies it already exists. This sometimes means a roadmap section reads as less visually exciting than a fully mocked-up feature would, but we think that trade is worth it for accuracy, particularly given the professional and regulated context this product is designed for.
As features move from roadmap to in-development to prototype to (eventually, where appropriate) validated functionality, we update the labels rather than leaving earlier language in place. Consistency here is an ongoing editorial responsibility, not a one-time classification exercise.
Why this discipline matters for a company like ours
We're building in a space — pharmacist medication review — where overstating capability carries real professional and safety weight, well beyond the usual costs of marketing hype. Being precise about prototype versus demo versus roadmap is one of the more concrete ways we can demonstrate, in how we communicate rather than just in what we say, that we take that weight seriously.
This is also, practically, useful for our own team: a shared status vocabulary keeps engineering, design and any outward-facing communication describing the same product in the same terms, which reduces the chance of drift between what's built and what's said about it.
Insights articles explain how this product and its demonstration are designed. They are not clinical guidance and do not represent guideline recommendations.