Twelve days. A working healthcare booking product — patient-facing booking flow, provider scheduling, availability management, confirmation emails, and a basic admin view. In production. Not a prototype. Not a Figma mock. Running on real infrastructure with real data.
When we tell clients this, the first reaction is usually skepticism. The second is: "What did you cut?"
Everything. We cut almost everything. That's the point.
Day 0: The Scope Definition Ritual
Before we write a line of code, we run a scope session. It takes 2–3 hours and it's the most valuable time in the entire engagement. The output is three lists:
Week 1 / Week 2 / Later
Week 1 contains only what makes the product usable for the first real user in the primary use case. Week 2 is what makes it good. Later is everything else — which, in our experience, often never gets built because the market feedback from Week 1 changes the roadmap entirely.
For the healthcare MVP, the scope session produced this:
Week 1 (non-negotiable):
- ─Patient books an appointment with a provider
- ─Provider sees their schedule and upcoming bookings
- ─Email confirmation to patient
- ─Basic availability rules (hours, blocked dates)
Week 2:
- ─Cancellation and rescheduling
- ─Provider-facing notes per booking
- ─SMS reminders
- ─Multi-location support
Later:
- ─Insurance integration
- ─Intake forms
- ─Video consult links
- ─Analytics dashboard
The client's first instinct was to include SMS reminders in Week 1. We pushed back. It's not blocking. A patient can receive an email confirmation and still show up. SMS is a retention feature, not a booking feature. It moved to Week 2. That decision alone saved 1.5 days.
The Tech Stack That Enables Speed
Speed is partly discipline, but it's also technology selection. We reach for the same stack on almost every MVP because we've learned what removes friction and what introduces it.
- ─Next.js (App Router) — full-stack in one repo, file-based routing, API routes alongside UI. No context switching between frontend and backend repos.
- ─Tailwind CSS — no naming decisions, no stylesheet management, composable design tokens out of the box. Design iteration is fast.
- ─Clerk or Auth.js — hosted authentication. We do not build auth. Ever. Not for an MVP. The edge cases in auth (password reset, session management, rate limiting, email verification) will consume a week if you roll it yourself.
- ─Neon or Supabase — hosted Postgres with a generous free tier and good DX. We're writing SQL or using Prisma, not managing database infrastructure.
- ─Resend — transactional email that works in 20 minutes. Not SendGrid. Not configuring SES. Resend.
- ─Vercel — deployment is a git push. No DevOps, no CI/CD setup, no infra decisions.
The pattern: own the product logic, delegate everything else to a hosted service. Every hour you spend configuring infrastructure is an hour you didn't spend building the thing the user actually touches.
The Feature Triage Framework
When scope creep hits (it always hits), we use a single filter:
"Does this feature change whether the first user can complete the core action?"
If yes, it's Week 1. If no, it isn't.
This sounds obvious until you're in the room with a client who has strong opinions about the color of the confirmation email or whether there should be a "preferred provider" flag in the booking flow. Both came up. Both moved to Later.
The structured checklist we run at the end of each day:
- ─Can a patient book an appointment end-to-end without help?
- ─Does the provider see the booking?
- ─Does the patient get a confirmation?
- ─Are there any flows that crash or produce an error?
- ─Is there a way to add/edit provider availability?
If the answer to any of the first four is "no," everything else stops until it's fixed. The fifth is necessary for the MVP to be self-serviceable by the client after handoff.
What Actually Surprised Us
The features were fine. The integrations almost killed the timeline.
The client had an existing CRM they wanted us to connect to so bookings would appear as leads. This was presented as "just a webhook." It was not just a webhook. The CRM's API had:
- ─OAuth with a non-standard token refresh cycle
- ─Rate limits that weren't documented
- ─A sandbox environment that behaved differently from production
- ─A required field for "lead source" that had an enum of 47 values, none of which were obviously correct
That integration cost us 2 days. We had budgeted 4 hours.
This is the most common source of timeline slippage we've seen across every MVP we've built: third-party integrations that are harder than they look. Our rule now is to triple the estimate for any integration involving an external API we haven't used before, and to scope them as Week 2 if they're not strictly required for the core flow.
The Hidden Cost of "Just One More Thing"
"Can we just add a waitlist feature?" Sounds like an afternoon. It's not.
A waitlist means: tracking availability in real time, notifying waitlisted patients when a slot opens, handling cancellations that trigger notifications, deciding what happens when two waitlisted patients both try to claim the same slot, and adding UI for providers to manage the waitlist.
Every "just one more thing" is a surface area expansion. It adds UI, database schema, edge cases, and testing surface. It rarely adds proportional value to the MVP's core hypothesis.
We learned to say: "That's a great feature. What's on the Later list we can trade it for?" Usually the client pauses. Usually nothing gets traded. Usually the thing doesn't ship in the MVP.
What an MVP Is Not
A few things we correct in almost every initial conversation:
An MVP is not a beta. A beta has most of the features but rough edges. An MVP has almost no features but works flawlessly for the one thing it does.
An MVP is not a prototype. A prototype demonstrates a concept. An MVP runs in production and handles real user data.
An MVP is not a first draft of your full product. It's a question with a working answer. "Will users book appointments through this system?" — that's the question. Everything else is premature.
An MVP is not fast by accident. The 12-day timeline was the result of extremely deliberate choices: which framework, which services, which features, and which conversations to have at day 0 instead of day 8.
Speed Is a Design Decision
The most important reframe we've made in how we talk about MVPs: speed is not a constraint imposed on quality. Speed is a product decision made about scope.
A 12-day MVP doesn't mean 12 days of mediocre work. It means 12 days of exceptional focus on one well-defined problem. The discipline to cut everything else is harder than any technical challenge in the build.
The healthcare client launched. They got their first real bookings in week 2. The CRM integration shipped in week 3. The SMS reminders shipped in week 5. By week 8, they had signal from real users that completely changed their Week 2 and Later roadmap.
That's what a real MVP does. It gets you to the signal faster than any other method, and it changes what you build next.
If you're trying to figure out whether your idea is scope-ready for a fast build, let's talk.