The Health Tech Build Sequence: What to Ship First When Evidence Comes Before Funding

Analysis of H1 2026 investment concluded that regulatory progress, pilot programmes, clinical validation, and initial enterprise customers have increasingly become prerequisites for fundraising rather than outcomes of it. Investors now want to see execution before funding the scaling of it.

Read that again if you are building something. The classic sequence was raise, build, then validate. The current sequence is validate, then raise. That single reversal changes what your first build has to be.

The market context makes it sharper. US digital health raised 14.2 billion dollars in 2025, up 35 percent, and Q1 2026 brought 4 billion across 110 deals with an average deal size of 36.7 million, the highest since late 2021. But nearly 60 percent of that quarter came from a dozen rounds of 100 million or more. Rock Health described a market that is active but selective, a market of haves and have nots. Capital exists. It is concentrated, and it goes to companies that have already reduced uncertainty.

So the question is not what is the minimum you can ship. It is what is the smallest thing that produces evidence. Below is the sequence, with the gate that has to clear before each phase earns its budget.

Phase 0. Before anything gets built. Weeks 0 to 4.

This phase produces documents, not software, and skipping it is the most expensive decision available to a health tech founder.

Four things get written down. Who the buyer is, specifically, including whether the person with the problem is the person with the budget. What the regulatory posture is, meaning whether you are clinical decision support, a medical device, a wellness product, or infrastructure, and what that implies. What the reimbursement or revenue path looks like, because investors in this sector ask about payer mechanics before user growth. And what evidence would convince a sceptical clinical buyer, written as a specific measurable claim.

That last one is the important one. If you cannot state the claim, you cannot design the thing that proves it, and everything downstream is guesswork with a burn rate attached.

Gate. You can write the evidence claim as a single sentence with a number in it. If not, do not build.

Phase 1. The evidence instrument. Months 1 to 3.

This is the healthcare MVP, and it is not a small version of the product. It is the smallest thing capable of producing the claim from Phase 0.

Sometimes those coincide. Often they do not. A workflow tool that saves clinicians time needs an instrumented version measuring time, not a feature complete version with a marketing site. A triage product needs a way to compare its output against ground truth. Build the measuring apparatus into the product from the start, because retrofitting measurement is the most common reason a pilot generates a nice anecdote and no data.

Design matters here more than founders expect, and for one specific reason. In a clinical setting an unusable product produces no evidence at all, because nobody uses it long enough to generate any. That makes UI and UX design part of the evidence infrastructure rather than a later polish phase. Woltrio's MVP development work in healthcare is scoped around this, pairing design and instrumentation in the same phase.

Gate. A real clinical user completes the core task unassisted, and the system records what happened well enough to support or refute your claim.

Phase 2. One site, real conditions. Months 3 to 6.

Now you find out whether the thing survives contact with an actual organisation.

This phase is mostly integration and security, which is why founders consistently underestimate it. You will need a business associate agreement, a security review, and some route to the data. That last one is where timelines go. Reading from a certified EHR through FHIR is a solved pattern, but which resources are exposed, which scopes are granted, and how long the vendor's app review takes are all vendor specific and calendar driven.

The engineering underneath is unglamorous. Access control, audit logging, and a data model that will not need rebuilding at the second site. Woltrio handles this through backend development and cloud engineering, and where the product sits close to the record system, alongside custom EMR and EHR development.

Gate. The product runs in one real environment, with real data, and the evidence claim is measurable in production rather than in a demo.

Phase 3. The second site, and the thing that actually kills companies. Months 6 to 12.

The second site is the real test, because the first one was won by a champion and the second one has to be won by the product.

This is where pilot purgatory sets in. Enterprise health system sales cycles run twelve to eighteen months, and a large number of startups die holding a folder of unpaid pilots. The failure is rarely technical. It is that a pilot with no conversion mechanism attached is a research project the startup is funding on behalf of the health system.

Two defences. Agree the conversion criteria before the pilot starts, in writing, including what result triggers a paid contract. And make deployment at site two meaningfully cheaper than site one, which is an architecture decision made back in Phase 2, not a sales decision made now.

Gate. A second site, ideally paying, and a repeatable deployment path.

What not to build in year one

Three things founders build early and regret.

A configurable everything. Flexibility built before you know which axis matters produces a product that does many things adequately and nothing convincingly.

Your own record system. Unless the record system is the product, integrate rather than rebuild. This is the single most common scope error in health tech.

Features that duplicate what the incumbent will bundle. Which brings us to the harder problem.

The moat problem, stated honestly

Incumbent record vendors have moved into adjacent categories, most visibly ambient documentation. When the incumbent bundles a native alternative, an external tool has to justify itself against something already installed, already integrated, and already paid for.

Commentary through 2026 has been blunt about the consequence. The era of endless pilots is over, and success now requires deep integration and immediate operational value.

That is not an argument against building. It is an argument for choosing a problem the incumbent will not bundle, which usually means one that is speciality specific, workflow deep, or dependent on data the platform vendor does not hold. Test that question in Phase 0, while it is still cheap to answer. Where the answer points toward AI development or automation, the same rule applies: pick the workflow the platform will not model well, not the one it will ship next quarter.

Where Woltrio fits

Woltrio builds Phase 1 and Phase 2 for health tech founders, which in practice means an instrumented MVP that produces evidence, then the integration and security work that lets it run somewhere real.

The most useful thing a development partner does at this stage is push back on scope. Most first briefs contain a feature set sized for the company the founder intends to build rather than the evidence the next raise requires. Cutting that back is not caution, it is sequencing, and in a market where validation now precedes capital it is the difference between a raise and a runway problem.

Start with a scoped discovery from Woltrio.