MedAscend: From Prototype to First Customer

MedAscend is a healthtech startup spun out of Dundee University, founded by medical students building an AI-powered clinical training platform. When I joined in October 2025, the product worked: the core AI logic was sound and the concept had won awards, but the platform was architecturally stuck in prototype territory. They needed enterprise clients to grow, and enterprise clients need things that prototypes don't have.

The setting

The stack was a Hono app on Cloudflare Workers, TypeScript, HTMX, Tailwind, DaisyUI, SQLite. Functional, lightweight, well-suited to the product. But the data model wasn't designed for multiple organisations. The workaround was to create additional admin users and hang account data from them, which technically separated things but wasn't a real tenancy model as there was no role-based access, no granular permissions, and no architectural guarantee of isolation. It worked for demos and small pilots, but it wouldn't survive the scrutiny of a university IT security review.

Beyond the data model, there was no CI pipeline, no environment separation (dev, staging, production), and the deployment process was manual. The founders were demoing from the same environment they were developing against, which is a process fraught with danger, with the risk that one deployment issue could bring everything down.

My Work

The biggest piece of engineering was redesigning the database layer to support multi-tenancy. This meant migrating from the flat admin-user model to a proper account structure where each organisation exists in isolation, with its own users, roles, and data boundaries. On top of that I built a full RBAC system to handle granular permissions that could be configured per-tenant, so a university administrator could control exactly what their staff and students could access.

I also set up the operational foundations: a CI pipeline that deployed to multiple environments, separate staging and production instances, and dedicated demo environments for conference presentations. The founders presented at two conferences during my time there, and having stable, isolated environments for those demos meant they could show the platform confidently without risking their production data.

What happened after

Within the five months I was there, the platform went from a prototype that couldn't serve multiple organisations to an enterprise-ready system that landed its first university customer. The tenancy and RBAC work was the prerequisite for that deal as without it, the university's IT team wouldn't have signed off.

When I left in March 2026, the platform was stable, the pipeline was running, and the founders had what they needed to continue onboarding their customer and pursuing further institutional contracts independently.

If you're building a product that's outgrown its prototype architecture, or you need enterprise features to unlock institutional sales, I've been through this process before. Get in touch.