How we built an AI healthcare MVP in 21 days (and what we learned)

A two-person founding team came to us in late February. They had three pilot clinics ready to test their courier-dispatch product — but only if it was live by the end of March. The previous agency they’d talked to had quoted five months and refused to touch protected health information without a signed Business Associate Agreement (BAA) in place.

They had three weeks. They had a Notion doc full of feature ideas. And they had no working product.

This is how we shipped.

The first call: scope compression, not feature negotiation

Most agency calls start with “tell us your features, we’ll quote you a price.” Ours started with a different question: what does the pilot clinic need to see on day one to keep using this for week two?

The founders had listed 17 features. We pushed back on every one. By the end of the call we had four:

1. A clinic operator can create a courier pickup request in under 30 seconds.
2. A driver gets a notification with an address and a one-tap “accept” flow.
3. The clinic operator can see, in real time, whether a courier has accepted, picked up, or delivered.
4. The driver can mark “delivered” with a signature image.

Everything else — billing, reporting, analytics, multi-region support — got pushed to a Phase 2 doc that we never reopened during the 21 days. That doc was the difference between shipping and not shipping.

The hardest part of an MVP isn’t writing the code. It’s saying no to the founder’s good ideas while protecting their great idea.

Day 1–3: HIPAA-aware foundation

We had a hard rule from the start: PHI is untouchable. Patient names, diagnoses, anything that could identify a patient — none of it would flow through our test environments, our developer machines, or any third-party service that didn’t have a BAA in place.

Concretely:

• Database: AWS RDS Postgres in a HIPAA-eligible account, single-AZ to start (cost), with point-in-time recovery enabled.
• Auth: Magic links via Resend (which is HIPAA-eligible under the Resend BAA), no passwords to leak.
• SMS to drivers: Twilio (HIPAA-eligible). The SMS body never contained patient info — only an opaque pickup ID and a deep link.
• Hosting: Vercel for the dashboard (no PHI ever rendered server-side outside the authenticated session), with all PHI fetches going through a single backend route under our control.
• Encryption: TLS everywhere, column-level encryption on PHI-adjacent fields using pgcrypto with keys in AWS KMS.

Two things we didn’t do, even though they would have saved time:

• We didn’t use a third-party logging service. Our backend logged to CloudWatch directly, and we had a strict allowlist of fields that could be logged. PHI was on the deny list with a runtime check that would crash the request if it leaked.
• We didn’t use any “AI features” in the MVP itself. The founders wanted a “smart route optimizer” on day one. We told them no — not because we couldn’t build it, but because no clinic operator was going to trust a black-box route on day one. Routing went into Phase 2.

Day 4–14: weekly delivery, no surprises

We ran two one-week sprints. Each one ended with a Friday demo over Loom — five minutes max, with a clickable preview URL the founders could play with all weekend.

Sprint 1 (week 2): Operator dashboard + pickup creation flow + driver SMS. We mocked the driver app with a mobile web view.

Sprint 2 (week 3): Real driver app (PWA, installable, no app store), accept/pickup/deliver flow, real-time status sync via Supabase Realtime for non-PHI fields only (status changes, timestamps).

By Friday of week 3 — day 21 — the first pilot clinic created a real pickup, a real driver accepted it, drove to a clinic in Brooklyn, picked up a sample, and marked it delivered. We watched it happen on the operator dashboard from a Slack huddle.

What we learned

1. Scope compression is the entire job

The 17-feature spec wasn’t wrong. It was just premature. Every feature we cut was something we could ship in week 6, week 10, week 16 — once we knew which clinics were actually using the product and how. Cutting 13 features in the first 60 minutes of the engagement was worth more to the founders than any single feature we built.

2. HIPAA isn’t slow, it’s a constraint that forces clarity

Every architectural decision had a single clear test: does this touch PHI? If yes, it goes through the locked-down path. If no, we used whatever was fastest. The constraint actually sped us up because we never had to debate edge cases.

3. Weekly demos beat status meetings, every single time

We had zero standups with the founders during the 21 days. Just a Friday Loom, a written changelog, and a Slack thread for each demo. They told us afterward they felt more in the loop than with their previous in-house engineer.

4. The “AI” part can wait

The founders had pitched the company as “AI-powered medical courier dispatch.” But the AI features (route optimization, predictive ETAs, fraud detection) were Phase 2 work. Phase 1 was just “does the basic loop work, and do clinics trust it?” Once we had that, the AI work was easy to layer on — and the founders had real data to test it against, which made the AI 10× better than what we could have built guessing.

Where they are today

Three pilot clinics turned into 11 paying clinics over the next 90 days. The founders closed a $750K seed round eight weeks after our launch. We’ve kept building with them ever since — Phase 2 (route optimization), Phase 3 (multi-region), Phase 4 (the AI product they originally pitched).

Twenty-one days bought them everything that came after.

If you’re a founder with a 4-to-8-week window, send us a message on WhatsApp — we’ll tell you in the first 10 minutes whether it’s compressible.