Start With Classification, Not Code

"Mobile medical applications" is not a marketing phrase. It is the name the FDA gives to a specific category in its guidance, Policy for Device Software Functions and Mobile Medical Applications. A mobile medical application is a mobile app that meets the statutory definition of a medical device. Whether your idea lands inside that definition decides almost everything downstream: your budget, your timeline to first revenue, the size of your seed round, and the multiple an acquirer will eventually pay. So the first page of a serious plan is not the app concept. It is the classification test.

The FDA sorts app functions into three buckets. Knowing which one you are in before a single screen is designed is the difference between a 12-week build and an 18-month regulated programme.

• Regulated device functions: the app diagnoses, treats, cures, mitigates or monitors a disease or condition, or turns the phone into a medical instrument. An ECG that flags atrial fibrillation, an insulin-dose calculator, a continuous glucose display. These need FDA clearance or approval.
• Enforcement-discretion functions: the app meets the device definition on paper but is low risk, so the FDA has said it does not intend to enforce. Simple symptom logs, medication reminders, condition-education tools. You still document your reasoning; you do not file a submission.
• Not a device: general wellness and administrative software. Step counters, appointment booking, wellbeing journals with no disease claim. No FDA involvement, provided the marketing copy stays out of clinical claims.

The trap that sinks first-time founders is claim creep. An app marketed as "general wellness" but whose in-app text says it "detects" or "recommends treatment for" a condition is classified on the claim, not the label. Your plan should state the intended-use sentence in plain language and show which bucket it produces, because every investor with healthcare experience will look for exactly that sentence. In the UK the equivalent starting point is the free MHRA stand-alone software and apps flowchart, which walks the same logic to a UK class.

If your concept sits closer to clinical decision support or artificial intelligence, it is worth reading our companion guides on the AI clinical care business plan template and the broader artificial intelligence healthcare business plan template alongside this one, because the classification thresholds shift once an adaptive algorithm is making or influencing a clinical call.

A Realistic Regulatory & Launch Timeline

Generic app timelines assume you ship in three months. A Class II mobile medical application does not work that way, because the clinical evidence and quality-system work run in parallel with the code and often outlast it. Here is the sequence a funded, regulated build actually follows. Treat it as the operations backbone of your plan.

1. Months 0–2 Classify and scope. Run the FDA three-bucket test and the MHRA flowchart. Write the intended-use statement, pick your target class, and identify a candidate 510(k) predicate device. This week of work reshapes the entire budget.
2. Months 1–5 Stand up the quality system while you build the MVP. ISO 13485 processes and IEC 62304 software-lifecycle records are started now, not retrofitted. Design controls, risk file (ISO 14971) and cybersecurity plan run alongside development.
3. Months 4–9 Clinical evaluation and validation. Generate the evidence your class requires, from a literature-based clinical evaluation for lower-risk software to a prospective study for higher-risk claims. This is the line item investors scrutinise first.
4. Months 8–14 Submit. File the 510(k) in the US (90-day statutory review, realistically 6–12 months with hold letters) or compile the UKCA technical file and book the approved-body assessment. Adaptive AI functions attach a Predetermined Change Control Plan.
5. Months 12–18 First market entry and post-market surveillance. Launch to the first payer, provider network or DiGA-style channel. Stand up the post-market surveillance system that UK regulations have required since June 2025, plus complaint handling and periodic reporting.

The reason this timeline matters commercially is cash. A wellness app can be revenue-positive in a quarter. A regulated mobile medical application is a cost centre for 12 to 18 months, then flips hard once clearance opens the reimbursement door. Your plan needs to show the investor the exact month the curve turns, and how much runway sits between now and then.

What It Costs to Build and Clear

Starting a mobile medical applications business typically requires $60,000 to $450,000 (£45,000 to £350,000), and the spread is enormous for one reason: a wellness app and a Class II device that happens to run on a phone are barely the same project. The bottom of the range is a HIPAA-compliant app with no submission. The top is a cleared device carrying real patients, where the quality system, clinical evidence and regulatory filing add cost that has nothing to do with writing code.

Cost breakdown

• HIPAA-compliant MVP build (3–4 months): $35,000–$65,000 (£28K–£52K). A production-grade version able to carry real patients runs $150,000–$200,000. Topflight, 2025
• HIPAA and security uplift over an equivalent non-regulated app: roughly 20–50% of the base build. Zenesys, 2025
• Quality system to ISO 13485 with IEC 62304 lifecycle records: $25,000–$70,000 (composite estimate).
• 510(k) preparation and submission (consultant plus the FY user fee): $40,000–$120,000 all-in (composite estimate).
• Clinical evaluation or real-world evidence study: $30,000–$250,000 depending on class and claim (composite estimate).
• Annual cloud, monitoring, penetration testing and post-market surveillance: $18,000–$60,000 per year (composite estimate).

Funding routes

US founders most often blend an SBA 7(a) loan (up to $5M, terms to 25 years) with early payer or provider pilots and angel capital; SBA-eligible software businesses use the programme to bridge the pre-clearance gap. In the UK the Start Up Loans scheme offers up to £25,000 per founder at 6% fixed with mentoring, and this category is unusually well served by Innovate UK grants and NHS innovation funding, which do not dilute equity and are catnip to seed investors. Germany's DiGA fast-track is a funding route in disguise: a listed app is reimbursed by statutory insurers, so the state effectively becomes your first paying customer. Our $1,000/£800 bespoke plan formats the financials for whichever mix you are targeting, including SBA-compliant projections and grant-ready evidence plans.

The Compliant Build: Stack & Tooling

Investors and NHS buyers now ask about your architecture, not just your idea, because a mobile medical application inherits obligations that ordinary consumer apps never touch: audit logging, data residency, interoperability standards and a documented software lifecycle. The plan's operations section should name the stack and show it maps to those obligations. The table below is a starting reference, not a mandate, and every choice should be justified against your class and target market.

Two practical notes founders miss. First, retrofitting IEC 62304 lifecycle records onto finished code is far more expensive than writing them as you go, which is why the timeline above starts the quality system in month one. Second, a build partner who has never shipped a regulated device will quote you a wellness-app price and deliver a wellness-app architecture, and you discover the gap during the submission when it is most costly to fix. The plan should name build partners with medical-device experience or budget for the uplift explicitly.

Approvals: FDA, MHRA and DiGA

This is the section that separates a fundable mobile medical applications plan from a hopeful one. It is also where founders most often underestimate both cost and time. Below are the three routes that matter most, each with the concrete evidence a lender or investor will want to see referenced.

United States

• 510(k) premarket notification for a Class II device with an available predicate. Around 61.5% of FDA-cleared prescription digital therapeutics reached market this way. Statutory review is 90 days; realistic timelines run 6–12 months with hold letters. NCBI/PMC regulatory study, 2025
• De Novo classification when the app is genuinely novel and has no predicate, the route Natural Cycles used for digital contraception. It runs longer, typically 12–18 months.
• Predetermined Change Control Plan (PCCP) for adaptive AI functions, now expected inside the submission under 2025 FDA guidance, so an app that learns can be updated without re-filing each time. FDA digital health guidance summary, 2025
• HIPAA Security and Privacy Rules plus Business Associate Agreements with every vendor touching protected health information.

United Kingdom

• UKCA marking under the UK Medical Device Regulations 2002. Class I self-certifies; Class IIa and above need an approved body to review the technical file, typically £15,000–£60,000 and 3–9 months. CMS digital health guide, UK
• DTAC, the Digital Technology Assessment Criteria, covering clinical safety (DCB0129), data protection, technical security, interoperability and usability. Critically, DTAC is assessed per NHS buyer, so a ten-trust rollout means defending the same evidence pack ten times. NHS England, 2025
• Post-market surveillance regulations in force since June 2025, requiring a live vigilance and reporting system from day one of sale. RegDesk MHRA summary, 2025

Germany and the EU

Germany's DiGA fast-track, run by BfArM, is the most founder-friendly reimbursement path in Europe. A CE or UKCA-marked Class I or IIa app can be listed provisionally for 12 months while it generates evidence of a positive healthcare effect, then permanently. By late 2025 the directory held 56–58 apps, and statutory insurers had reimbursed roughly €234M cumulatively by December 2024, with spend up 71% year on year. BfArM, 2025 Across the EU, MDR Rule 11 pushes most clinical-decision software to Class IIa or higher, which means a notified body rather than self-certification. If Europe is on your roadmap, model the notified-body queue, because it is a real constraint.

Cybersecurity is now part of the submission, not an afterthought

One theme runs through all three jurisdictions: regulators no longer treat security as a separate IT concern. In the US, the FDA expects a documented cybersecurity plan, threat modelling and a software bill of materials inside the premarket submission, and a device that cannot show how it protects against unauthorised access can be refused on that basis alone. In the UK and EU, security and data protection are explicit lines in the technical file and in DTAC. Practically, that means budgeting for penetration testing, a coordinated vulnerability-disclosure process and a patching commitment from the start, and writing them into the plan's operations section. A founder who can describe their cybersecurity posture in a sentence, and their patching cadence in another, reads as someone who has built a regulated product before, even if they have not.

How a Mobile Medical Application Makes Money

The most common revenue mistake in this category is building the model on consumer subscriptions. App-store subscriptions of $4.99 to $14.99 a month churn hard and rarely cover the cost of a regulated build. The money that actually pays for clearance sits on the payer and provider side. A credible plan usually blends the four routes below and shows which one carries the model.

• B2C subscription: $4.99–$14.99/month direct to the patient. Useful for reach and data, weak as a standalone economic engine.
• B2B per-member-per-month (PMPM): contracts with employers and health plans, typically $1.50–$8 PMPM. Predictable, scalable, and the backbone of most funded models.
• Provider-side RPM billing: clinics bill Medicare remote-patient-monitoring codes (CPT 99453, 99454, 99457, 99458) and share revenue with the app vendor.
• Statutory reimbursement: Germany's DiGA listing and NHS procurement under DTAC turn the health system itself into your customer.

A worked example: the RPM revenue-share model

Take a US clinic partner that enrols 250 chronic-care patients on an RPM-enabled mobile medical application. Per patient per month the clinic bills 99454 (device supply, about $52.11) plus 99457 (first 20 minutes of management, about $51.77), roughly $103.88, with 99453 (about $21.71) once at set-up. Prevounce RPM code guide At a 30% revenue share the app vendor books about $31.16 per patient per month, which is $7,790 a month, or roughly $93,500 a year from a single clinic. Add a second and third clinic of similar size and the vendor clears about $280,000 ARR from 750 monitored patients, before any consumer subscription revenue is counted. Rates are national Medicare averages and vary by locality, but the structure is the point: recurring, clinically embedded, and far stickier than an app-store subscription.

Gross margins on the software layer run 70–85%. Net margin is usually negative until somewhere between month 18 and month 30, because regulatory and clinical spend is front-loaded. Your plan should make that J-curve explicit rather than hide it, because sophisticated healthcare investors trust a model that shows the trough more than one that pretends it does not exist.

The unit economics investors actually check

A believable model in this category rests on three numbers, and it is worth stating each one plainly rather than burying it in a spreadsheet tab. The first is acquisition cost. In a B2C model, blended cost to acquire a paying patient through app-store and paid channels commonly lands between $30 and $120, which is precisely why consumer-only models struggle: at a $9.99 monthly price with heavy early churn, payback can stretch past the point most patients stay. The second is retention, expressed as the share of users still active at month three and month twelve, because a treatment app that is not used is neither clinically effective nor commercially valuable, and clinical outcomes and retention are the same curve viewed twice. The third is contract value on the B2B side: a single PMPM contract at $4 across 5,000 covered lives is $240,000 of annual recurring revenue from one signature, which is why a plan that shows two or three signed or piloted payer relationships is worth far more than one promising a million downloads. Model all three, show the sensitivity, and name the assumption behind each. That is the section a healthcare investor turns to first.

Cleared Apps Worth Benchmarking Against

Most guides in this category stop at "the market is growing." The number that actually helps a founder is the shortlist of apps that have already made it through the exact door you are trying to open. Referencing them by name in your plan does two things: it proves you understand the regulatory bar, and it gives an investor a valuation anchor. The list of FDA-cleared prescription digital therapeutics is short enough to know cold. In one 2025 study of thirteen such products, roughly 61.5% cleared via 510(k) and 38.5% via De Novo, which is itself a useful signal about which pathway a novel claim tends to force. NCBI/PMC, 2025

Benchmarks worth naming, and the reason each matters to a plan:

• EndeavorRx (Akili Interactive): an ADHD treatment for children and the first video-game-style prescription digital therapeutic cleared by the FDA. It is the reference case for "the software itself is the treatment."
• Natural Cycles: digital contraception cleared through the De Novo pathway. The benchmark for a novel claim with no predicate, and for the value of a strong prospective evidence base.
• reSET and reSET-O (now with PursueCare): substance and opioid use disorder. The early template for prescription DTx and for the reimbursement fights that followed.
• Somryst and the Sleepio/Daylight family (Big Health): insomnia and anxiety. Proof that behavioural-health software can carry both a clearance and a payer contract.
• AspyreRx (Click Therapeutics) and Stanza (Swing Therapeutics): type-2 diabetes and fibromyalgia respectively, showing the model extending into chronic physical conditions.

Two lessons come out of studying these directly. First, almost none of them won on the app experience alone; they won on the evidence dossier and the reimbursement relationship, which is why those sections dominate a fundable plan. Second, the ones that struggled commercially after clearance usually had a strong regulatory story and a weak payer story, the mirror image of the mistake most first-time founders make. Your plan should show both halves solved on the same page.

Market Size, Demand and Where the Growth Is

The global mHealth apps market was worth about $37.5 billion in 2024 and is forecast to reach roughly $86.37 billion by 2030 at a 14.8% CAGR. Grand View Research, 2025 The detail that matters for a mobile medical applications plan is composition: the medical segment, not fitness, drove 73.0% of 2024 revenue, which tells you demand is concentrated in exactly the regulated, clinically embedded products this guide is about.

Read together, the numbers describe a market where demand is real and growing double digits, but where the winners are clinically credible products with a reimbursement path, not consumer novelties. That is the strategic story your plan should tell, and it is why the regulatory and revenue sections above sit before this one: the market rewards the founders who solved those two problems first.

Mistakes That Sink First-Time Plans

Across the mobile medical application plans we review, the same six errors recur. Each one is cheap to avoid on paper and expensive to fix in code, contracts or a submission. Screen your draft against them before you send it to anyone with a cheque.

• Building first and classifying second. The FDA three-bucket test and the MHRA flowchart are free and take about a week. Retrofitting IEC 62304 lifecycle records onto finished code costs months and can force a partial rebuild.
• Marketing "wellness" while the app screen says "diagnose." Regulators classify on the claim, not the intention. If any in-app text detects, diagnoses or recommends treatment, you are a device regardless of how the store listing is worded.
• Modelling revenue on consumer subscriptions. The money in this category is payer- and provider-side: RPM billing, PMPM contracts, DiGA listing, NHS procurement. A model that leans on $9.99 a month rarely survives diligence.
• Ignoring post-market obligations. UK post-market surveillance regulations came into force in June 2025, and adaptive AI functions now need a Predetermined Change Control Plan in the US submission. Investors read these as operating costs, not footnotes.
• Treating DTAC as a one-off. It is assessed per NHS buyer, so a ten-trust rollout means defending the same evidence pack ten times. That is a sales-cycle assumption that belongs in the go-to-market model.
• Under-budgeting clinical evidence. Sophisticated healthcare investors read the evidence plan before the financials. A thin evidence line signals a founder who has not yet understood the category.

None of these are exotic. They are simply the questions a healthcare investor or NHS commissioner asks in the first fifteen minutes, and a plan that has answered them in advance clears the room a good deal faster than one that has not.

More Founder Questions, Answered Briefly

These come up on nearly every call with a first-time mobile medical application founder. They are the questions behind the search, so the plan should answer them before an investor asks.

Does my health app need FDA approval?

Only if it meets the device definition and is not covered by enforcement discretion. Diagnosing, treating or monitoring a condition puts you in scope; a step counter or education tool usually does not. Run the three-bucket test first; most disputes are settled by the intended-use sentence and the in-app claims, not the app category.

What separates a mobile medical application from a wellness app?

The claim. Two apps can measure the same heart-rate signal; the one that says "detects atrial fibrillation" is a device and the one that says "track your heart rate" is wellness. Regulators read the claim, so the classification is a copywriting and intended-use decision as much as an engineering one.

How much does it cost to build a HIPAA-compliant medical app?

A HIPAA-compliant MVP is commonly $35,000–$65,000, with the HIPAA and security work adding roughly 20–50% over an equivalent non-regulated app. A production-grade build able to carry real patients is $150,000–$200,000, and regulated devices add the QMS, submission and evidence lines on top.

How do medical apps make money if consumers won't pay?

Through payers and providers. PMPM contracts with employers and health plans, RPM billing shared with clinics, and statutory reimbursement through DiGA in Germany or NHS procurement in the UK. Consumer subscriptions are a supporting channel, rarely the core engine.

What is DTAC and do I need it to sell to the NHS?

DTAC is the NHS's baseline assessment for digital health tools, covering clinical safety, data protection, security, interoperability and usability. Most NHS deployments require it, and because it is assessed per buyer, a multi-trust rollout repeats the same evidence review for each trust. Budget it as a sales-cycle cost, not a one-off compliance tick.

Sample Business Plan Preview

Here is an extract from a mobile medical application plan written in our house style, so you can see how the regulatory and reimbursement logic sits inside the narrative rather than bolted on at the end:

What's in the Template

Every Avvale business plan template includes the standard sections, pre-structured, plus the extra sections a mobile medical application needs to be taken seriously by a healthcare investor or an NHS commissioner:

• Executive Summary: including the intended-use sentence and target device class up front, where investors look first.
• Regulatory Strategy: classification rationale, chosen pathway (510(k), De Novo, UKCA, DiGA), and the evidence plan.
• Clinical Evidence Plan: what you will prove, how, and to whose standard.
• Company Overview: legal structure, ownership, and the founding clinical and technical story.
• Market Analysis: mHealth sizing, medical-segment demand, and reimbursement outlook.
• Reimbursement & Revenue Model: PMPM, RPM billing, DiGA and NHS procurement, with unit economics.
• Operations & Quality: the ISO 13485/IEC 62304 stack and post-market surveillance approach.
• Go-to-Market: payer, provider and channel strategy, plus the DTAC sales-cycle reality.
• Management Team: founder bios, clinical advisers, and the regulatory or QA hire investors will expect.

The optional Financial Forecast add-on (included in our $300/£250 and $1,000/£800 packages) provides a 5-year Excel model with income statement, cash flow, balance sheet, break-even analysis, and the pre-clearance runway calculation this category lives or dies on. For deeper market inputs, our market research and content service supplies the sourced sizing, competitor benchmarking and reimbursement analysis that sit behind the narrative.

Frequently Asked Questions