How to Start a Healthtech Startup Without VC (2026 Guide)

Short answer: To start a healthtech startup without VC, build software for the business side of care (scheduling, intake, practice management, patient messaging, clinician admin or general wellness) instead of software that diagnoses or treats. Learn exactly when HIPAA applies, choose hosting and email vendors that will sign a business associate agreement, sell to small independent practices per practitioner, and leave anything that looks like a medical device until revenue, not investors, can pay for the regulatory work.

Healthtech has a reputation as a venture-only industry, and for some products that is fair. Clinical trials, device clearances and hospital sales cycles really do eat years of runway. But a large part of health software is ordinary workflow software sold to clinics, therapists and practitioners who pay monthly and stay for years. That part can be bootstrapped, and some well-known companies prove it. This guide covers which product shapes work, what the rules actually say in the US, UK and EU, what BAA-ready infrastructure costs today, real examples, a labelled worked cost example, a stage table with gates, a 12-month plan, mistakes and a checklist.

Every price, rule and quote below was checked on the source's own page on 11 Nov 2026. The analysis in between is ours and is marked as such.

TL;DR#

• The expensive part is being a medical device. FDA defines software as a medical device as software "intended to be used for one or more medical purposes" without being part of a hardware device (FDA). The annual establishment registration fee alone is $13,785 for FY 2027 (FDA MDUFA fees).
• Pick a device-free shape. Admin, scheduling, intake, billing helpers, patient communication and general wellness tools sit outside device rules if you keep their intended use clean.
• HIPAA is a contract question first. If you handle protected health information for a covered entity, the rules require a "written contract or other written agreement" with you (45 CFR 164.502). Your vendors then need to sign one with you.
• BAA-ready infrastructure has public prices. Vercel's HIPAA BAA is $350 a month on Pro (Vercel pricing), Aptible Production is $499 a month plus usage (Aptible), Supabase offers HIPAA as a paid add-on from the $599 Team plan (Supabase).
• Consumer health apps are not rule-free. The FTC's Health Breach Notification Rule was updated in 2024 to clarify "its coverage of developers of many health applications" (Federal Register).
• Bootstrapped healthtech exists. Cliniko says "we don't take money from investors" (Cliniko) and serves over 65,000 health professionals.

Disclosure: ZeroRaised publishes this guide and runs a launch site for bootstrapped products. ZeroRaised has no commercial relationship with any vendor or company named here, and no links in this post are affiliate links. This is general information, not legal, medical or regulatory advice. Health regulation depends on your exact product, claims and location, so talk to a lawyer who works with health data and, if you go near diagnosis or treatment, a regulatory consultant before you launch.

Why healthtech looks like a VC-only game (and when it is not)#

Founders usually give three reasons why healthtech needs venture money: regulators move slowly, hospitals buy slowly, and data rules are frightening. All three are real. But they hit very different products with very different force.

It helps to split health software into two families:

1. Clinical products. Software that diagnoses, triages, monitors a condition, recommends a treatment or analyses medical images and signals. These products often meet the legal definition of a medical device, and they need clinical evidence, a quality management system, registration and sometimes premarket clearance. They tend to sell to hospitals and health systems with long procurement cycles. This family is capital-heavy by design.
2. Operational products. Software that helps people run care: booking, reminders, intake forms, notes templates, invoicing, insurance paperwork, messaging, staff rotas, client portals, and consumer wellness apps that encourage healthy habits. These are normal SaaS businesses with stricter security and contracts. They usually sell to independent practices that decide in a week, not a year.

Almost every bootstrapped health software company we could verify sits in the second family. That is not a coincidence. Operational software earns revenue from the first customer, and the regulatory cost is mostly contracts, security and careful wording.

Our read: the trap is drifting from family two into family one through features. "We just flag patients whose scores look worrying" is a clinical decision feature. "The app tells users whether their symptoms need a doctor" is triage. Each sounds like a small addition to a scheduling or wellness product, and each can change your regulatory category. Decide which family you are in and design your roadmap so you stay there until you can afford to move.

Bootstrappable healthtech shapes#

Here is how common health software ideas line up against capital needs. The regulatory column is our summary of the rules covered below, not a legal determination for your product.

If you want the general case for picking an industry and owning its workflow, our guide to building a vertical SaaS without VC covers niche selection, pricing and distribution. This guide goes much deeper on what is specific to health.

Is your software a medical device? FDA, MHRA and EU rules#

You do not need to become a regulatory expert. You do need to recognise the line well enough to keep your product on the right side of it, and to know when to pay someone who is an expert.

United States: FDA#

The definition. FDA describes software as a medical device (SaMD) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device" (FDA SaMD). The key phrase is intended. Your intended use is read from what you say: your website, app store listing, onboarding and sales deck. A scheduling tool marketed to "improve patient outcomes by catching deterioration early" invites a very different reading from the same tool marketed to "cut no-shows".

General wellness. FDA updated its General Wellness guidance on 6 January 2026, replacing the 2019 version (FDA). The guidance says a general wellness product has:

"(1) an intended use that relates to maintaining or encouraging a general state of health or a healthy activity, or (2) an intended use that relates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition."

That is the door most consumer fitness, sleep, stress and habit apps walk through. Read the full guidance before you write your marketing copy, because the boundary is about claims as much as features.

Low-risk software and enforcement discretion. FDA's Policy for Device Software Functions and Mobile Medical Applications (September 2022 version) says that "Some software functions may meet the definition of a medical device, but because they pose a lower risk to the public, FDA intends to exercise enforcement discretion over these devices" (FDA). Enforcement discretion is not an exemption you can rely on forever, and it does not cover everything, but it explains why many simple patient-facing tools ship without clearance.

Clinical decision support. If you are building for clinicians, FDA's Clinical Decision Support Software guidance matters. It was reissued on 29 January 2026, superseding a version from 6 January 2026 (FDA CDS guidance). Software is outside the device definition under this route only if it meets all four statutory criteria, which the guidance sets out as software:

1. "not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system"
2. "intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines)"
3. "intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition"
4. "intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient"

Our read: criterion four is where AI features get into trouble. A black-box model that tells a clinician what to do, without showing a basis they can independently review, is hard to fit inside it. If your clinician tool summarises, retrieves guidelines and shows its sources, you are in a much better position than if it outputs a recommendation and a confidence score.

What being a device costs. Just to register a device establishment, FDA's fee is $13,785 for FY 2027 (1 Oct 2026 to 30 Sep 2027), up from $11,423 for FY 2026 (FDA MDUFA fees, Federal Register). That is before any clearance submission, quality system, clinical evidence or consultants. It is a useful number to keep in mind when someone says "we will just get FDA clearance later".

United Kingdom: MHRA#

The MHRA says software is a medical device when it is "intended to be used for one or more medical purposes", and that intended purpose is "the use for which the device is intended according to the data supplied by the manufacturer" (MHRA intended purpose guidance). Its software and AI guidance adds that "In the UK, many of these products are regulated as medical devices" (MHRA).

If you are a device, the obligations are concrete. Devices placed on the Great Britain market "must have a UKCA marking or a CE marking", the MHRA will accept CE marked devices "until, at the latest, 30 June 2030", and "All medical devices ... must be registered with the MHRA" (MHRA, updated 20 Feb 2026).

European Union: MDR Rule 11#

EU software classification is stricter than many founders expect. Rule 11 of the Medical Device Regulation, as reproduced in the Commission's MDCG 2019-11 guidance, says:

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: death or an irreversible deterioration of a person's state of health, in which case it is in class III; or a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb."

It continues: "All other software is classified as class I" (MDCG 2019-11 Rev.1). Class IIa and above need a notified body, which is a serious cost and timeline for a bootstrapped team.

Our read: the EU rule is why "decision support" is a phrase to avoid in a bootstrapped European health product's first year. Software that helps a clinic run its diary is not deciding anything about diagnosis. Software that suggests which patients need follow-up is starting to.

When HIPAA applies (and when it does not)#

HIPAA is the rule US healthtech founders worry about most and understand least. The good news: whether it applies to you is mostly a structural question you can answer before writing code.

Covered entities and business associates#

HIPAA applies directly to covered entities. The regulation defines them as "(1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter" (45 CFR 160.103). In practice, most clinics that bill insurance electronically are covered entities.

It also applies to business associates: vendors that handle protected health information (PHI) on a covered entity's behalf. The regulation says a covered entity may let a business associate "create, receive, maintain, or transmit protected health information on its behalf, if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information", and that those assurances "must be documented through a written contract or other written agreement or arrangement" (45 CFR 164.502). That written agreement is the business associate agreement, or BAA.

If you sell practice software to a therapist who bills insurance and your app stores their client notes, you are almost certainly a business associate. They will ask you to sign a BAA, and you will need your own BAAs with every vendor that stores or transmits that data for you: hosting, database, email, SMS, backups, error tracking, support inbox and AI APIs.

The decision in practice#

Our read: the cheapest compliance decision is often to keep PHI out of a product entirely. A staff rota tool, a clinic marketing site builder or an inventory tracker can be sold to health businesses without ever touching patient records. If the product needs patient data, accept that you are a business associate from day one and design for it, because retrofitting is far more expensive.

Penalties: why the BAA matters#

HIPAA civil money penalties are set out in 45 CFR 102.3 and adjusted for inflation. The current figures in the eCFR table are (45 CFR 102.3):

For a bootstrapped company, even the lowest tier stacked across many records is an existential number. The practical protection is not a big compliance budget: it is a short list of vendors with signed BAAs, encryption, access controls, audit logs and a written risk assessment you actually keep up to date.

SOC 2 vs HIPAA#

They are different things. HIPAA is law that applies based on what you do. SOC 2 is a voluntary audit report that larger buyers ask for. Small practices rarely ask for SOC 2; hospital and health system security questionnaires often do. Our guide to SOC 2 for bootstrapped startups covers costs, timing and how to answer questionnaires before you have a report. Do not start a SOC 2 audit for your first ten clinic customers.

Consumer health apps: the FTC Health Breach Notification Rule#

If your app is outside HIPAA, health data is still not a free-for-all in the US. The FTC's Health Breach Notification Rule was amended in a final rule published on 30 May 2024 (89 FR 47028), effective 29 July 2024. The FTC said the changes "clarify the Rule's scope, including its coverage of developers of many health applications" (Federal Register via govinfo).

The rule centres on personal health records, defined as "an electronic record of PHR identifiable health information on an individual that has the technical capacity to draw information from multiple sources and that is managed, shared, and controlled by or primarily for the individual" (16 CFR 318). A wellness app that pulls data from a wearable and lets users log symptoms can fit that description.

If there is a breach, notice must be sent "without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach of security" (16 CFR 318.4). Violations are subject to civil penalties under the FTC Act, currently $53,088 per violation after inflation adjustment (16 CFR 1.98).

Our read: under the 2024 rule, sharing health data with an advertising or analytics vendor without authorisation can itself be a breach of security. For a bootstrapped wellness app, that means no ad pixels and no third-party trackers that see health data, and treating your analytics setup as a compliance decision.

UK and EU: data protection and NHS assurance#

UK GDPR and GDPR: health data is special category#

The ICO says UK GDPR gives "extra protection" to several kinds of data, including "data concerning health", which means "personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status" (ICO). You need both a lawful basis and a separate condition for processing it, plus a data protection impact assessment is very likely. Our GDPR checklist for solo SaaS founders covers the basics (DPAs, subprocessors, records); add special category handling on top of it for any health product sold in the UK or EU.

Selling into the NHS#

You do not need the NHS to build a UK health business: private clinics, physios, dentists, therapists and wellness practitioners are a large market on their own. If you do want NHS customers, expect these assurance steps:

• Data Security and Protection Toolkit (DSPT). An "online self-assessment tool that allows organisations to measure their performance" against the National Data Guardian's 10 data security standards. The toolkit says: "All organisations that have access to NHS patient data and systems must use this toolkit" (DSPT).
• Clinical safety standards. NHS England says "DCB0129 sets out requirements for technology manufacturers" and "DCB0160 covers how health and social care organisations deploy and use these systems safely" (NHS England). As a supplier, DCB0129 is yours: plan for a documented clinical risk management process and a clinically trained person to own it, and read the standard itself for the full requirements. NHS England ran a review of both standards in 2026, so check the current versions before you start.
• DTAC. NHS buyers use the Digital Technology Assessment Criteria to assess digital health suppliers across clinical safety, data protection, technical security, interoperability, and usability and accessibility. Download the current version from NHS England Digital rather than relying on an old copy, because the criteria are revised from time to time.

Our read: each of these is doable for a small company, but together they are a project. Win private practices first, and treat the NHS as a stage-three market once you have revenue, a clinical safety officer (often a clinician advisor with the right training) and time to fill in forms.

The stack: BAA-ready infrastructure and what it costs#

Choose vendors before you write code, not after the first clinic asks for a BAA. Every vendor in your PHI path needs to sign one with you. Here is what we could verify on vendor pages today.

Two notes on payments and video. We could not find a Stripe page saying Stripe signs BAAs, and Stripe's own healthcare guide warns that "Not every payments provider will do this: confirm before you commit to an integration" (Stripe). Our read: design billing so that payment records contain only what is needed to charge (name, amount, invoice number), not diagnoses or appointment types. For video, Doxy.me offers "a completely free version for providers" and lists a BAA on its pricing page, which can let you integrate rather than build telehealth.

Our read on stack choice:

• Fastest to compliant: a managed PaaS built for HIPAA (Aptible) or a PaaS add-on, plus Google Workspace with the BAA accepted. You trade a higher fixed fee for fewer things to configure.
• Cheapest at scale, most work: AWS or Google Cloud directly, using only eligible services. The BAA is easy to accept; configuring encryption, logging and access correctly is your job.
• Do not build an EHR backend from scratch. If your product needs clinical data models, look at Medplum's free tier for prototyping, OpenEMR (below) for reference, or a platform API like Healthie before writing your own FHIR store.
• Audit your hidden PHI paths. Error tracking, log drains, support tools, analytics, AI APIs and email providers all leak PHI easily. Either get a BAA or scrub data before it reaches them.

Real bootstrapped and customer-funded examples#

We looked for health software companies that describe their funding on their own pages. Several popular "bootstrapped" examples turned out to have raised outside money, so we list what we could verify and are clear about the rest.

Cliniko (Australia): bootstrapped practice management#

Cliniko's story page says it "was founded in Melbourne, Australia in 2011", that co-founder Joel Friedlaender quit his job "Using a loan that had just been approved to renovate their house", and that today "Over 65,000 health professionals use Cliniko, and we're still not keen on outside investment" (Cliniko story). A 2016 post by Friedlaender explains: "Often we get approached with offers of investment from venture capitalists and other investors. We're not interested" and "Cliniko is 100% privately owned" (Cliniko blog). A 2023 values post repeats: "We don't take money from investors" (Cliniko).

Its pricing is a useful template. Prices are in US dollars and bands are by number of practitioners (Cliniko pricing):

Lesson: Cliniko chose the operational family (booking, notes, invoicing for allied health), priced simply, and sold to independent practices. Fifteen years later it serves tens of thousands of practitioners without investors.

Jane (Canada): clinician-founded, later growth equity#

Jane's story page says "Jane's story begins in 2011" and "In 2014, Jane was ready to launch", and lists Ali Taylor as "Co-Founder / Clinical Owner" alongside Trevor Johnston, "Co-Founder / Lead Developer" (Jane story). Jane is not a no-investor company: growth equity firm Tidemark has published its own announcement of an investment in Jane (Tidemark). We include it for two lessons that hold regardless: a clinician co-founder who owned a clinic, and simple per-practitioner pricing. Jane's pricing page shows Balance at USD $59 a month, Practice at USD $79 and Thrive at USD $99, and says "We do not have a free trial" (Jane pricing).

Lesson: a clinic owner co-founder gives you a first customer, domain knowledge and credibility with other clinicians. Taking growth money years later is a choice you can make from strength.

OpenEMR: open source electronic health records#

OpenEMR describes itself as "Fully Open-Source. Free Software, Always and Forever" and says "OpenEMR is ONC Certified!" (OpenEMR). Its wiki lists ONC Health IT Certification for OpenEMR 8 with a certification date of "January 30, 2026", and its history goes back to a 2001 release (OpenEMR wiki). The code is GPL-3.0 licensed on GitHub and stewarded by the OpenEMR Foundation.

Lesson: you do not need to build an EHR to build a health business. Many small companies earn revenue around open source health software: hosting, support, customisation and integrations. If your skills are in infrastructure, that is a legitimate bootstrapped model.

Halaxy (Australia): free core, paid add-ons#

Halaxy's about page says its "free core software includes all the essential features you need to run your practice" (Halaxy), and a 2025 post explains: "we'd prefer to make a little bit of money from a lot of people" and "we only charge for optional add-ons" (Halaxy blog). Its about page also notes that it "received grant funding from the Australian Government through Austrade's Export Market Development (EMDG) program", a non-dilutive grant. Halaxy does not make an investor or no-investor statement, so we cite it for its model, not as a bootstrapped claim.

A counter-example worth knowing#

Practice Better, a practice platform for wellness professionals, announced a "$27 Million Growth Investment" in April 2023 (Practice Better). It is a good company, but not a bootstrapped example. Check before you quote any health software company as "bootstrapped" in your own pitch or content: many have raised money quietly.

Validation: talk to clinicians before you build#

Health software fails more often from a wrong workflow than from wrong code. Clinicians have strong habits, little spare time and real consequences when software gets in the way.

1. Pick one practice type. "Clinics" is too broad. "Solo pelvic health physiotherapists" or "group practices of 3 to 10 therapists" is a market you can find and talk to.
2. Run ten workflow interviews. Ask clinicians to walk you through yesterday: booking, intake, notes, billing, follow-up. Watch for the step they complain about without being asked.
3. Find the money owner. In small practices the clinician is often the buyer. In group practices it is often a practice manager. In hospitals it is a committee. Your first market should be one where the person in pain can also say yes.
4. Pre-sell. Ask for a paid pilot or a deposit before you build. A clinician who will not pay $50 for a tool that saves them hours is telling you something.
5. Get a clinical advisor. Pay a practising clinician for a few hours a month, or offer advisor equity, to review workflows and wording. For UK NHS work this person may later become your clinical safety officer if they have the right training.

Our guide to validating a SaaS idea before building has the full method, including interview scripts and pre-sale tactics. In health, add one question to every interview: "Who else would need to approve this?" The answer tells you your real sales cycle.

Selling: small practices vs hospitals#

Small independent practices (solo therapists, physio clinics, dental and chiro practices, dietitians, wellness practitioners) are the bootstrapper's market. Our read from how these businesses buy:

• The owner decides, often within days.
• They pay by card, monthly, per practitioner.
• They find tools through peers, professional associations, Facebook groups, conferences and search.
• They switch when their current tool annoys them enough, and they rarely switch again once settled.
• They will ask for a BAA (US) or data processing terms (UK and EU), and sometimes a short security questionnaire.

Hospitals and health systems buy differently. Expect procurement, security review, legal review, integration requirements (often HL7 or FHIR with an EHR), pilots, and committees. Our hedged read: cycles of many months are common, and a bootstrapped company can run out of patience before the contract arrives. Hospitals are a stage-three market for most bootstrapped founders, entered after a base of practice revenue makes the long cycle affordable.

Pricing patterns. The examples above all use per-practitioner pricing: Cliniko from $45 a month for one practitioner, Jane from USD $59 a month, Healthie Essentials at $49.99 a month on monthly billing. Our read: per-practitioner pricing matches how practices think about cost (per clinician who earns revenue), scales naturally as a clinic grows, and is easy to explain on a pricing page. Add-ons (insurance billing, SMS, AI scribe features) are a common second revenue line, as Jane's AI Scribe add-on at $15 a month per practitioner shows.

Funding without VC: grants, revenue and patience#

Customer revenue is the main engine, but health is one of the best categories for non-dilutive money.

• Grants. The US NIH runs one of the largest SBIR/STTR programmes; see seed.nih.gov for current solicitations and award limits, which vary by institute. Our startup grants guide covers SBIR reauthorisation, NSF, Innovate UK, EIC and how to apply. Grants suit clinical and research-heavy products more than admin SaaS.
• Pre-sales and paid pilots. Practices that helped design a tool often pay for a year upfront at a discount.
• Services first. Building custom forms, integrations or reports for clinics can fund the product while teaching you the workflow.
• Revenue-based financing once you have recurring revenue.

Our overview of ways to fund a product without venture capital compares these options side by side.

Worked example: a scheduling and intake tool for US therapy practices#

This is an illustrative example using published prices from the vendor pages above. Your costs will differ, and the price you charge is a placeholder.

Product: online booking, intake forms, reminders and a client portal for small US therapy practices that bill insurance. It stores PHI, so you are a business associate.

Option A: Vercel plus Supabase

Option B: Aptible

Revenue side (illustrative). Suppose you charge $49 per practitioner per month, close to Cliniko's and Healthie's entry prices.

• Option B break-even on known costs: $506 / $49 = about 10.3, so 11 paying practitioners, before usage, SMS and legal costs.
• Option A break-even on known costs: $976 / $49 = about 19.9, so 20 paying practitioners, plus whatever the Supabase add-on costs.
• At 100 practitioners you would bring in $4,900 a month; on Option B, known fixed infrastructure would be about 10% of that.

Our read: the fixed cost of BAA-ready infrastructure is the real difference between health SaaS and ordinary SaaS. A normal side project can start on free tiers; a HIPAA product starts at hundreds of dollars a month. That pushes you to pre-sell before building and to price per practitioner rather than per practice. Before your first BAA, also budget for a lawyer to review your BAA template and terms, and for cyber insurance. We have not put numbers on those because they vary too much to quote honestly.

Stage table with gates#

This is our editorial framework. Move to the next stage only when you pass the gate.

A 12-month plan#

This plan is ours, for a solo founder or a pair building a non-device practice tool.

Months 1-2: choose and validate. Pick one practice type you can reach. Run ten workflow interviews. Write a one-paragraph intended use statement and check it against FDA's wellness and CDS guidance (or MHRA guidance in the UK). Decide whether you will handle PHI.

Month 3: pre-sell and set up compliance basics. Get three paid pilots or deposits. Choose your stack from BAA-ready vendors. Have a lawyer review a BAA template, terms and privacy policy. Accept vendor BAAs (AWS Artifact, Google Workspace Admin console, Vercel billing, and so on).

Months 4-6: build the narrow MVP. Booking, intake, reminders or whatever the core workflow is. Encryption at rest and in transit, role-based access, audit logs, MFA. No ad pixels, no third-party analytics on pages with health data. Write a risk assessment and keep it in your repo or docs.

Months 7-8: pilot. Onboard pilots personally. Sign BAAs with each. Fix workflow friction weekly. Collect quotes and permission to use them as references.

Month 9: launch. Public pricing page with per-practitioner pricing, a security and privacy page, and self-serve signup. Use our product launch checklist for bootstrapped makers for the launch itself, and post in the professional communities your buyers use.

Months 10-12: grow and harden. Add one add-on that customers ask for (SMS reminders, insurance paperwork, an integration). Run an incident response drill. Decide whether your next segment needs SOC 2, NHS assurance or hospital-grade security, and only start that work if a paying buyer is waiting.

Common mistakes#

1. Marketing your way into device rules. Words like "diagnose", "detect", "predict risk" or "treatment recommendations" on your website can change your regulatory category. Write copy for workflow outcomes: fewer no-shows, faster intake, less admin.
2. Picking vendors before checking BAAs. You build on a host or email provider that will not sign a BAA, and the first clinic asks for one. Migration under deadline is painful.
3. Forgetting hidden PHI paths. Error logs with patient names, support emails with diagnoses, AI prompts containing session notes. Each needs a BAA or scrubbing.
4. Ad pixels in a health app. Under the FTC's updated rule, unauthorised sharing with ad or analytics vendors can count as a breach.
5. Starting with hospitals. Long cycles drain bootstrapped runway. Start with practices that can say yes this month.
6. Building an EHR. Unless you have years of runway, integrate or extend instead.
7. No clinician in the room. Software designed without clinical input gets the workflow wrong, and clinicians notice instantly.
8. Treating compliance as a one-off. Risk assessments, access reviews and vendor lists need updating as you add features.
9. Treating "HIPAA compliant" as a badge. Our read: compliance is something you do continuously, not a logo you buy. Be precise on your website: say what controls you have and that you sign BAAs.
10. Copying a VC-funded competitor's roadmap. Funded competitors can afford clinical features and hospital sales. You win by being simpler, cheaper and more focused.

Checklist before your first paying clinic#

• One practice type chosen; ten interviews done
• Intended use statement written and checked against FDA wellness and CDS guidance (or MHRA, MDR Rule 11)
• Decision recorded: do we handle PHI or health data at all?
• Every vendor in the PHI path has a signed BAA (hosting, database, email, SMS, backups, logs, support, AI)
• Payment records kept free of clinical details
• BAA template, terms and privacy policy reviewed by a lawyer
• Encryption, MFA, role-based access and audit logs in place
• Written risk assessment and incident response plan, including a 60-day breach notification process for FTC rule cases
• No ad pixels or third-party trackers on pages with health data
• UK/EU: lawful basis plus special category condition, DPIA, DPA with customers
• Clinical advisor engaged; clinical safety officer identified if selling to the NHS
• Per-practitioner pricing published

Frequently asked questions#

Can you start a healthtech startup without VC funding?#

Yes, if you build software for running care rather than software that diagnoses or treats. Practice management, scheduling, intake, billing helpers, patient messaging and general wellness apps can be built and sold like normal SaaS with extra security and contract work. Cliniko, founded in 2011 and used by over 65,000 health professionals, says it does not take money from investors. What usually needs large funding is becoming a regulated medical device or a care provider.

Does my health app need to be HIPAA compliant?#

Only if you are a covered entity or a business associate. Covered entities are health plans, health care clearinghouses and health care providers that transmit health information electronically in standard transactions. If you create, receive, maintain or transmit protected health information on behalf of one of them, you are a business associate and need a written agreement (a BAA). A consumer app that people use on their own, without a provider or plan behind it, is often outside HIPAA, but the FTC Health Breach Notification Rule can apply instead. This is not legal advice.

Is my health software a medical device?#

It depends on intended use. FDA defines software as a medical device as software intended for one or more medical purposes without being part of a hardware device. Admin software, scheduling and billing tools are generally not devices. Products that only encourage a general state of health can fall under FDA's General Wellness guidance (updated January 2026), and clinician-facing decision support can fall outside device rules if it meets all four criteria in FDA's Clinical Decision Support guidance. In the UK and EU, the MHRA and MDR Rule 11 apply. Get regulatory advice before adding diagnostic or treatment features.

How much does it cost to start a healthtech startup?#

A software-only health product can start for a few hundred to about a thousand dollars a month in BAA-ready infrastructure. Published examples: Vercel Pro is $20 a month plus a $350 a month HIPAA BAA add-on, Aptible Production is $499 a month plus usage, and Supabase Team starts at $599 a month with HIPAA as a separately priced add-on. Add legal review of your BAA and privacy terms, insurance and security work. Becoming a regulated device costs far more, starting with FDA's $13,785 annual establishment registration fee for FY 2027.

What is the best healthtech idea for a bootstrapped founder?#

Our read: a narrow admin or workflow tool for one type of independent practice you understand, such as intake and reminders for solo therapists, scheduling for physiotherapy clinics, or documentation templates for a specific specialty. Small practices buy faster than hospitals, pay per practitioner, and need fewer integrations. Avoid anything that diagnoses, triages or recommends treatment until you have revenue and regulatory advice.

Launch your health product without investors#

ZeroRaised is a launch directory for products built without institutional VC. When your first practices are live and your security page is up, submit your product to ZeroRaised for free and put it in front of makers and early adopters. For more playbooks on building in regulated industries without investors, join the ZeroRaised newsletter.

Sources#

• FDA: Software as a Medical Device (SaMD), last checked 11 Nov 2026
• FDA: General Wellness: Policy for Low Risk Devices (January 2026), last checked 11 Nov 2026
• FDA: Clinical Decision Support Software guidance (January 2026), last checked 11 Nov 2026
• FDA: Policy for Device Software Functions and Mobile Medical Applications, last checked 11 Nov 2026
• FDA: MDUFA user fees, last checked 11 Nov 2026
• Federal Register: MDUFA fee rates for FY 2026, last checked 11 Nov 2026
• eCFR: 45 CFR 160.103 definitions, last checked 11 Nov 2026
• eCFR: 45 CFR 164.502 uses and disclosures, last checked 11 Nov 2026
• eCFR: 45 CFR 102.3 civil monetary penalty adjustments, last checked 11 Nov 2026
• Federal Register: Health Breach Notification Rule final rule, 89 FR 47028, last checked 11 Nov 2026
• eCFR: 16 CFR 318 Health Breach Notification Rule, last checked 11 Nov 2026
• eCFR: 16 CFR 1.98 civil penalty adjustments, last checked 11 Nov 2026
• MHRA: crafting an intended purpose for SaMD, last checked 11 Nov 2026
• MHRA: software and AI as a medical device, last checked 11 Nov 2026
• MHRA: regulating medical devices in the UK, last checked 11 Nov 2026
• European Commission: MDCG 2019-11 Rev.1 software qualification and classification, last checked 11 Nov 2026
• ICO: what is special category data, last checked 11 Nov 2026
• NHS Data Security and Protection Toolkit, last checked 11 Nov 2026
• NHS England: national review of clinical risk management standards, last checked 11 Nov 2026
• NHS England Digital: DTAC, last checked 11 Nov 2026
• AWS HIPAA compliance, last checked 11 Nov 2026
• Google Cloud HIPAA compliance, last checked 11 Nov 2026
• Vercel compliance docs and Vercel pricing, last checked 11 Nov 2026
• Supabase pricing and Supabase HIPAA docs, last checked 11 Nov 2026
• Aptible pricing, last checked 11 Nov 2026
• Render HIPAA docs, last checked 11 Nov 2026
• Fly.io healthcare, last checked 11 Nov 2026
• Cloudflare HIPAA, last checked 11 Nov 2026
• Medplum pricing, last checked 11 Nov 2026
• Twilio HIPAA, last checked 11 Nov 2026
• Google Workspace HIPAA and Google Workspace payment plans, last checked 11 Nov 2026
• Healthie pricing, last checked 11 Nov 2026
• Doxy.me pricing, last checked 11 Nov 2026
• Stripe: healthcare embedded payments, last checked 11 Nov 2026
• Cliniko story, Cliniko: investment, no thanks, Cliniko values and Cliniko pricing, last checked 11 Nov 2026
• Jane story and Jane pricing, last checked 11 Nov 2026
• Tidemark: Jane announcement, last checked 11 Nov 2026
• OpenEMR, OpenEMR wiki and OpenEMR on GitHub, last checked 11 Nov 2026
• Halaxy about and Halaxy blog, last checked 11 Nov 2026
• Practice Better growth investment announcement, last checked 11 Nov 2026
• NIH SEED: SBIR/STTR, last checked 11 Nov 2026