An MVP built to answer one question, not everything the founders wanted

The situation

Two founders with a clinical background and one with a technical one had built a prototype in Figma: a medication reminder app with reminders, a caregiver dashboard, pharmacy integration, insurance verification, a rewards system, and a chat feature for patients to message their care team. Early investor conversations had gone well. The feedback was consistent: come back with users.

The founders had a rough build estimate from a freelance developer for the full feature set, six months and a budget that would have consumed most of their remaining runway before a single patient touched the product. They needed something faster and smaller, but they weren't sure which features actually mattered to the question investors were asking, which was whether patients would use the thing at all.

Off-the-shelf healthtech platforms existed for parts of this, appointment reminders, basic patient portals, but none combined the specific adherence-tracking logic the founders had designed with the clinical team they'd consulted. Building around an existing platform would have meant bending the product to fit someone else's data model before they knew if the product itself worked.

Why custom development made sense

A generic reminder app would have answered a different question than the one the founders needed answered. The core hypothesis, that a specific adherence-tracking approach designed with input from actual clinicians would outperform a basic reminder, could not be tested on a platform built around a simpler assumption. The product needed to be custom enough to test the actual idea, and small enough to build in weeks, not months.

What was built

The engagement followed a discover, define, design, build, launch approach, compressed to fit the founders' runway.

Discover and define: One week went into separating what the founders wanted from what the pilot needed to prove. The twelve-feature plan got cut to three: medication reminders built around the adherence logic the clinical co-founder had designed, a simple confirmation flow so patients could log whether they'd taken a dose, and a basic view for the founders to see aggregate adherence patterns across pilot users. Pharmacy integration, insurance verification, and the rewards system were logged for later, contingent on the pilot showing the core loop worked.

Design and build: The mobile app was built cross-platform to reach both iOS and Android patients without doubling development time. The reminder logic was built as a standalone service from the start, so it could be improved or replaced without touching the rest of the app once real usage data came in.

Launch: The MVP launched to a 40-patient pilot group recruited through the founders' clinical contacts, with basic monitoring in place to track daily engagement and confirmation rates from day one.

What changed

The founders had a working product in patients' hands eight weeks after the engagement started, instead of the six months the original scope would have required. The pilot ran on a budget that left runway intact for the parts of the build that still mattered: refining the adherence logic based on real data, not guessing at features nobody had tested yet.

• Before: A twelve-feature plan, a six-month build estimate, and no usage data to bring to investors.
• After: A three-feature pilot live with 40 patients in eight weeks, generating the engagement numbers the seed round conversation actually needed.

Holding the MVP scope also meant the founders could change direction cheaply. When early pilot data showed patients wanted a way to see their own adherence trend, not just log a dose, that feature got added in week nine without reworking anything already built, because the reminder logic had been kept separate from the rest of the app from the start.

Beyond launch

Once the pilot confirmed the core loop worked, product engineering continued past the initial release. The caregiver dashboard, deferred from the original plan, was added as a second phase once the founders could point to real adherence data to justify it. The application was moved onto scalable cloud infrastructure ahead of the seed round, so a successful raise wouldn't mean an immediate rebuild.