Healthcare MVP Development: Scope to the Pilot Contract, Not the Product Vision

Somewhere around month eight of a healthcare build, a lot of founders find themselves in the same position. The product does what it was designed to do. Dashboards work, the audit log captures what it should, the FHIR endpoint returns valid responses, the SOC 2 evidence collection is on track. But deployment conversations with prospective pilot customers keep stalling in ways that feel oddly consistent from one hospital to the next. Different objections, same net result. No signed contract, no live users, and a runway number that keeps looking worse.

Digital health pilots die in bulk before they scale. Roughly 68% never make it out of the test phase, per NEJM data cited by Becker's Hospital Review, and Meg Barron at the AMA has been calling the pattern the "pilot cemetery" for years. Most products that end up there were not badly built. Many were built quite well. What most of them share is subtler than build quality. They were built against a general model of what a healthcare MVP should include, without a specific hospital's IT security review, workflow constraints, BAA terms, and change-management process sitting behind the design decisions. Two builds like that can look nearly identical on a feature spec and have very different odds of going live.

Why the SaaS playbook stops working

Founders coming from SaaS know the drill. Build the smallest useful thing, put it in front of users, watch what happens, iterate. This works in SaaS because deployment is the first step. Someone can sign up and use the product before any compliance review happens. Enterprise gates exist in SaaS too, but they arrive later, when the deals get bigger, and by then the product has usage data to argue with.

Healthcare inverts that timing. Before a single patient touches the product, the hospital runs it through a stack of gates: a vendor security review, an IT integration approval, a clinical workflow sign-off, a legal review of the BAA, and a risk assessment on every subprocessor. Any of those groups can end the deal. Most tend to raise objections at roughly the same time, near the end of what is often a 12 to 18 month evaluation cycle, when the founder has the least budget and time to respond.

That cycle is slow because a specific set of requirements runs against the product during it. An MVP built without any specific version of those requirements in mind has to try to pass every hospital's version at once. Most fail on at least one axis.

Sign the pilot before scope is finalized

Here is the change that helps. Sign one paid pilot commitment, even a small one, before scope gets locked. Get an LOI with a defined go-live date and defined success metrics. Then treat the requirements that customer produces during evaluation as V1's actual specification, and let the founder's model of what a healthcare product should include be the thing that flexes.

Every guide on healthcare MVP development says to pilot with one clinic. Most of them skip the part where the LOI has to be signed before scoping ends. When it comes after, the founder builds against a generic idea of a hospital, then tries to reshape a working product to fit a specific hospital's actual requirements. That reshaping is where a lot of MVP budgets disappear. When the LOI comes first, most of the scoping work becomes derivation rather than invention. Their security questionnaire answers what compliance ships. Their workflow answers which integrations matter. Their success metrics answer what data to capture from V1. Their subprocessor policy answers which vendors survive. Almost everything the customer does not need can be honestly deferred.

Most founders do not have a pilot customer engaged deeply enough to produce those artifacts before they have built something to show. So they build generically and scramble later. There is no elegant escape from the chicken-and-egg. What tends to work is being willing to spend six weeks on outreach and requirements-gathering with real prospects before writing production code. Six weeks feels wasteful when the Notion doc is full of features waiting to be built. It compresses months out of the actual build later.

What a pilot customer's evaluation produces

Five documents worth having in hand before scope locks:

A vendor security questionnaire. Hospital questionnaires run 100 to 300 questions covering the usual controls plus a version of "have you completed a SOC 2 Type 2 audit" as an early filter. Reading it before finalizing compliance tells you which specific tables need field-level encryption, which log fields the SIEM ingests, whether GCP is acceptable or the institution has standardized on Azure, whether a HIPAA-eligible subprocessor in Ireland passes review or US-only is a hard requirement.
IT integration requirements, in writing. For a chronic care pilot in an ambulatory clinic this might read "pull appointment data from athenahealth, write a note back after each session." For a clinical decision support pilot in an inpatient ward it might mean pulling vitals from the Epic Hyperspace context and writing recommendations back into the encounter note. From outside those look similar. In practice they use different FHIR resources, auth models, QA burdens, and timelines.
A full shadowed shift. Interviews produce clean sequenced descriptions of work. Shifts produce the real sequence, which is usually messier, faster, and constrained by things nobody mentioned in the interview — the scrub nurse who takes handoff at 7 AM, the attending who only checks the queue between rounds, the front-desk staff who need check-in to complete before the patient reaches the exam room, the medical assistant reconciling notes into the EHR later. UIs that made sense on the whiteboard often collapse to one screen with keyboard shortcuts once you watch the work happen under time pressure.
Two or three pilot success metrics. If the target is a 15% reduction in 30-day readmissions in the heart failure cohort, V1 has to capture admission and discharge events, cohort assignment, and the readmission window from day one. Adding instrumentation later, when the pilot review arrives asking for it, is much more expensive than building it in.
BAA template, subprocessor policy, and data residency requirement. Most enterprise health customers have their own BAA they expect you to sign, and it may require terms your default cloud stack cannot support. Some institutions will not accept a subprocessor located outside the United States even if that subprocessor is otherwise HIPAA-eligible. These constraints are cheap to accommodate in week one and expensive to accommodate in week twenty.

In practice you rarely have all five before scoping starts. Two or three, maybe. The rest come during the build. That is workable. Finalizing V1 scope with zero of them is not, because at that point the scope has no anchor other than the founder's model of what a healthcare product should include.

What this looks like in the field

Take a specific version. A founder building a remote patient monitoring product for cardiology practices spends her first six weeks on outreach and gets a paid pilot LOI signed with a mid-sized cardiology group before writing any production code. The LOI is small: 90 days, 50 patients, one specific readmission target as success. The pilot almost collapses in week three when the clinic's IT director departs and the replacement wants a fresh conversation. She works through it, gets requirements re-committed in writing, and only then starts the build.

The security questionnaire says GCP is fine and no non-US subprocessors, so vendor selection stays simple. Shadowing the nurse shows she needs a triage queue in the morning rather than a real-time dashboard, which cuts three planned screens. The EHR is athenahealth, so the FHIR scope narrows to reading appointment data and writing a monitoring note. Four months in, the pilot goes live. It goes live with rough edges. In week five, one patient's data mapping breaks and takes a full day to debug. In week seven, the practice's billing lead asks for a workflow adjustment nobody had thought about, and the team spends a weekend on it. But the practice manager introduces her to two other cardiology groups anyway, and one of them signs an LOI three weeks later.

That is roughly how a well-scoped pilot goes. Real ones have more complications than that. Data quality problems that only surface at scale, workflow surprises after go-live, contracts that get renegotiated when procurement rotates a new person in, champions who leave for another health system. The story is meant to demonstrate the direction of scope rather than a clean outcome. A build reverse-engineered from a specific customer's requirements tends to get deployed. A generic build built to a founder's model of what a healthcare product should include mostly does not. In a business where 68% of pilots die before deployment, direction of scope determines a lot.

If you are already six or nine months into a build without a signed pilot, feeling worse about it is not the useful move. The technical work is real work. HIPAA-eligible infrastructure keeps its value in a rescoped build, and so do most of the auth patterns, the RBAC model, and the audit logging plumbing. Get the LOI, even if the pilot is smaller than you wanted. Rescope V1 backwards from what that specific customer needs to go live. Some of what you built survives that rescoping unchanged. Some needs adjustment. Some, honestly, was speculative in a way that only becomes visible against a real customer's requirements. None of that work is wasted, though. It is what building without a spec looks like from the outside.

A note on AI in the build

This is also where AI matters in a healthcare build, though in a different place than most agency proposals put it. Most proposals talk about AI as a feature-cost driver: the chat interfaces, RAG, clinical decision support copilots that add 15 to 30 percent to a budget line. That captures a real cost. What it misses is that AI in the actual coding loop compresses the mechanical work that eats large fractions of any healthcare build: auth and RBAC scaffolding, audit logging plumbing, FHIR mapping, migration scripts, compliance test coverage. Cutting that time by half or more is a real thing, especially when paired with HIPAA-eligible defaults already available on the delivery side. A six-month reverse-scoped build becomes closer to a six-to-ten-week build. The customer's contract still does the scoping work. The tooling closes the gap between contract and go-live faster.

Where healthcare MVP scope lives

The scope of a healthcare MVP is more of a sales artifact than a product artifact. It lives, or should live, in the customer's contract terms, security questionnaire, workflow map, and BAA before it lives in the architecture doc. When it lives in the architecture doc first, the odds of deployment go down materially, because the doc is a guess about the customer's environment rather than a description of it.

For a founder about to scope V1, the first useful conversation is a sales one. It is about which specific pilot customer will sign an LOI before the build finalizes, and what that customer's requirements will do to the scope once they are in front of you. Anyone who has been through this cycle a few times is happy to have that conversation.

If it would be useful, booking a 30-minute call is the most direct way to have it.

Related reading: