You don’t need £150k to build an app — you need to test an MVP

One of the most common patterns our mentors see goes like this:

“We need to raise £150k.”
“Why?”
“To build the app.”
“Why build the app now?”
“Because we’ve written out all the amazing features! If we build it, clinicians will use it and commissioners will buy it… right?” 

Wrong.

In early-stage medtech, one of the costliest and sadly common mistakes is building before validating. Your job isn’t to ship a beautiful product; it’s to de-risk the riskiest assumptions as quickly and cheaply as possible, then invest time and money with confidence.

In this week’s Monday Masterclass we are talking all things MVP and lean experiments. Below is a practical, medtech specific menu of different approaches. For each one, we’ve included: what it is, when to use it, how to run it, signals to look for, evidence you get, and pitfalls/guardrails. Use these like tools in a kit, pick the one that tests your biggest unknown this week.
 

First principles: what exactly are you testing?

In medtech there are four buckets of risk. Your first MVP should target your biggest unknown now, in which of these areas does your biggest, unvalidated, leap of faith assumption sit:

1. Desirability — will clinicians/patients/admins want it enough to change behaviour?
2. Feasibility — can you deliver the outcome with today’s tech and workflow (even if manually)?
3. Viability — will a real buyer fund it; does the economics work for a Trust/ICS/private provider?
4. Acceptability — can this pass IG/safety/clinical workflow without surprises?

Start with one hypothesis. Define a clear stop/go threshold. Run the smallest experiment that can kill or strengthen it. Pick one of the options below and get out of the house and test your ideas!! 

1) Concierge MVP (white-glove and fully manual)

What it is: 

You deliver the promised outcome by hand for a tiny number of users. No app, no cutting edge platform. You’re embedded in the workflow, acting like a high-touch service. In essence you replace the technology with your hard work and problem solving ability. 

This is one of the most versatile approaches and something many of the founders we’ve coached have used successfully. 

When to use:

• You don’t yet know the right solution shape.
• You don’t have first hand – lived experience of the problem – and it’s solution. 
• You need deep discovery and to see the messy edge cases.
• Small, cooperative setting (one clinic/ward/team, early adopters).

How to run (step-by-step):

1. Speak to some potential customers, see if they would be happy for you to solve [the problem] that you’re working on.
2. Write a one-page “service brief” (the steps you’ll do manually).
3. Run the service for 2–4 weeks. Using spreadsheets, email, paper checklists, and/or phone calls, whatever works.
4. Time every step; log failure modes; capture verbatim quotes.
5. Charge something (even nominal) to test value and procurement friction.

Signals to look for: 

Repeat usage without you pushing; “Can we keep this going?”; one or more offers to pay; observable time savings, clear insight into how your solution can be ‘a better way’. 

Evidence you get:

• Clear understanding of JTBD (jobs-to-be-done – we’ll cover this in later blogs – google it for now!) and workflow map.
• A prioritised list of pains/gains; true “must-have” features.
• Early reference quotes and hopefully repeat customers (if you can convert your friendly team into early adopters of your new solution). 

Pitfalls & guardrails:

• Not scalable, that’s fine at this stage. Your aim here isn’t to scale and monetise, its to learn and validate. 
• Be transparent it’s a manual trial (no claims of automation).
• IG: minimise patient identifiable / sensitive data; agree data handling up front (controller/processor, storage, deletion).
• Don’t become free consulting—attach a decision date and a next step (pilot or pause).

2) Wizard-of-Oz MVP (hidden manual backend)

What it is: Users interact with a realistic front end (simple web app/form/prototype), but the “clever” part is done manually behind the curtain. You give the impression of a fully automated tool, and a similar customer journey however it relies on humans ‘doing the do’. 

When to use:

• You’re confident about the value prop and want to test end-to-end experience and willingness-to-pay before automation.
• You need realistic usage telemetry (drop-offs, turnaround times) without building a backend.

How to run (example only, you may need to flex this to your circumstances):

1. Build a thin front end (e.g. Figma clickable, Webflow/Carrd + Typeform).
2. Route tasks to humans via inbox/Slack/Airtable.
3. Return outputs within a target SLA (e.g., 4 hours) and measure.
4. Price it (pilot fee or per-use) and see if demand holds.

Signals: 

Users complete journeys unprompted; acceptable turnaround; tolerance for occasional rough edges; pricing conversations start.

Evidence you get:

• True time-to-value; perceived accuracy/quality bar.
• A spec for future automation based on how humans actually did the work.

Pitfalls & guardrails:

• Don’t mislead on clinical decision-making—if a person is making judgements, say so and ensure proper clinical oversight. Be careful with what you claim and how you position this one. It is not suitable to use a wizard of oz MVP in all cases. Trust is difficult to rebuild.
• Capacity caps (humans don’t scale)—that’s okay; you’re proving demand.

3) Piecemeal (assembled) MVP

What it is: 

You stitch together existing tools to mimic what your product will ultimately do these could include things like: Typeform / Airtable / Google Docs / Calendly / Stripe / Zapier.

Sidebar: this is actually how Tesla got started – they a battery and electric motor, but reused a Lotus car to build their roadster… worked out ok for them!! 

When to use:

• The innovation isn’t a novel algorithm or proprietary tech; it’s a new workflow and service wrap.
• You can prove value with off-the-shelf components.
• You have some engaged early adopters who won’t mind a slightly clunky solution so long as it solves their problem(s).

Example approach:

1. Map the journey (e.g. referral → triage → action → follow-up → reporting).
2. Assign a tool to each step and connect them (light automation only).
3. Pilot with a small cohort; track minutes of manual glue.

Signals: 

Consistent delivery; users don’t care that it’s “duct-taped”; genuinely solves a problem and people use it repeatedly. 

Evidence you get:

• A viable service blueprint.
• The exact “glue” steps that deserve real features later.
• In some cases a clear roadmap – as you can digitise key parts of the solution iteratively focussing efforts on the most critical steps to improve flow and function. 

Pitfalls & guardrails:

• Tool limits and branding seams where you switch from one product to another, if not properly managed this can feel jarring. Explain to pilot users it’s a prototype, true early adopters will often be ok with this. 
• IG: know exactly where data lives; prefer tools with UK/EU data hosting if working with NHS partners.

4) Single-feature MVP (do one thing brilliantly)

What it is: 

You launch only the core capability that defines your value (e.g., automated clinic letter summarisation), nothing else.

When to use:

• One feature clearly carries the value hypothesis.
• You want clean signal without noise from “nice-to-haves”.

Example use case:

1. Identify the highest-value task and the success metric (e.g., ≥50% reduction in time per letter).
2. Ship/demo just that flow to 5–10 power users.
3. Measure task success, time saved, repeat usage, and willingness to pay.

Signals: 

Users tolerate missing frills because the job is solved; they build workarounds to keep using it.

Evidence you get:

• A defendable before/after for one job.
• Insight into problem/solution fit. 

Pitfalls & guardrails:

• Don’t “sugar-coat” with extra features—prove the core first.
• Be explicit about scope to avoid feature creep in pilots.

5) Landing page & Fake-door tests (market and pricing)

What it is: 

A simple page and CTA to measure interest (join waitlist, book a discovery call, pre-order), or a “fake door” button to a not-yet-built feature. Personally we like the second option less and recommend being careful with it, again trust is important, however it is a legitimate technique so we’re mentioning it. 

When to use:

• You need to test messaging, ICP fit, and pricing before any build.
• You’re choosing between propositions or audiences.
   

Example approach:

1. Define: Clear promise, audience, outcomes, social proof (if any), single CTA.
2. Create a landing page, include sign up form
3. Generate Traffic: from founder outreach, niche communities, targeted ads (eg. Google PPC).
4. Optional ‘Fake-door’: a button for users to ‘buy’ Feature X when clicked it says ‘coming soon’ or something similar collects emails or books calls. NB Do not sell false promises – preorders are ok if you clearly specify thats what they are, but lying about a product or feature you don’t have is wrong and possibly illegal. 

Signals (benchmarks, directional): 

2–5% targeted opt-in; >30–40% of responders accept a call; replies mention concrete problems.

Evidence you get:

• Better understanding of your ICPs (Ideal Customer Profiles) language; objection patterns; interest by segment; early list.

Pitfalls & guardrails:

• Clicks ≠ cash. Always follow with conversations using [Link to: The Mom Test].
• As above – be honest, if a feature isn’t ready, say “Join the early access list”.
   

6) Explainer video (show, don’t build)

What it is: 

A 90–120s walkthrough of problem → context → how it works → expected results → CTA. 

Sidebar – look up the dropbox explainer video online – they raised an enormous amount of money off the back of it credit a lot of their success to the one initiative. Well worth doing a deep dive and watching the actual video

When to use:

• The concept is hard to visualise or involves multi-party workflow.
• You need a shareable asset for intros and conferences.

Example approach:

1. Script in plain English; avoid hype.
2. Record a Loom/Keynote screenflow with voiceover.
3. Send to targeted stakeholders with a one-pager and booking link.

Signals: 

Watch-through rates; inbound “can we pilot this?”, or “when is this being released”; forwards to colleagues.

Evidence you get:

• Whether buyers “get it” quickly; which bits confuse, which bits excite! 

Pitfalls & guardrails:

• Video is top-of-funnel, pair it with a concrete next step (pilot call).
• Don’t imply validated clinical outcomes if you’re pre-evidence.

7) Clickable prototype (Figma/Keynote)

What it is: 

A realistic, interactive mock-up of the top user journeys, no code, high learning.

When to use:

• You need usability and workflow feedback before any build.
• Stakeholders want to “see it” to engage.

How to run:

1. Map two core journeys (e.g., referral intake → dashboard → action → handover).
2. Build clickable screens; keep visuals simple.
3. Run five 30-minute usability sessions: “Please complete X while thinking aloud.”
4. Time tasks; note hesitations; ask “What would you expect to happen here?”

Signals: 

70–80% task success without prompting; suggestions to remove steps; alignment on terminology.

Evidence you get:

• Screen-level requirements; language that resonates; blockers to adoption.

Pitfalls & guardrails:

• Don’t over-polish; keep it changeable live in sessions.
• Capture “this won’t work here because…”—those are gold.

Medtech guardrails (read before you test)

• Safety & clinical claims: Do not imply autonomous diagnosis/therapy unless you actually do—and are taking the regulatory path. If a person is making a judgement (concierge/WoZ), say so and ensure appropriate clinical oversight.
• Information Governance: Even in scrappy MVPs, map data flows, define controller/processor, storage location, retention and deletion. Favour low-risk data (no PHI) until you must handle it.
• Service Evaluation vs Research: Most early NHS pilots can be scoped as service evaluations (improving a service), not research—avoid unnecessary burden. Keep scope tight, outcomes operational, and use a simple DPIA summary.
• Procurement realism: Buyers need a path from pilot to purchase. Document success metrics, economic case, and the exact next governance step.
   

Choosing your approach (quick map)

• Unclear solution / need discovery → Concierge
• Clear value prop; test end-to-end UX → Wizard-of-Oz
• Workflow innovation; no novel tech → Piecemeal
• One killer capability drives value → Single-feature
• Test market & price first → Landing page / Fake-door
• Need to visualise complex flows → Explainer video
• Validate usability & language → Clickable prototype

If two seem viable, pick the one you can execute this week with existing tools and real stakeholders.

Want more like this?

We hope you have found this masterclass useful. Check out our blog for other topics and sign up below for our mailing list and free access to our Medtech Founder’s Starter Pack, filled with advice and tools. 

See you here next week!! 

The Medtech Mentor team