Decide what you are treating

How to create a mental health app: the three decisions that come first

The practical answer to how to create a mental health app is to settle three questions before the first sprint: what you claim the product does for a condition, where the data a user types actually goes, and what happens the moment someone signals they are at risk. Those three answers set your regulatory path, your data architecture and your app store outcome. Most other choices in mental health app development, including the stack, the onboarding flow and the video vendor, can be revised later at reasonable cost. These three cannot, because each of them leaves a record.

Teams usually invert the order. The feature list gets written first (mood tracking, journalling, a chatbot, video sessions), compliance is bolted on before launch, and clinical evidence is promised for a later round. That sequence produces two predictable failures: a marketing claim the product is not licensed to make, and a data model that cannot be unwound without a migration and a public apology.

Is the mental health app market worth entering?

Yes, though the number you put in a board deck depends on which definition you accept. Global Market Insights sizes the mental health apps market at $8.2 billion in 2025, reaching $9.6 billion in 2026.² Fortune Business Insights values the same 2025 market at $7.48 billion.¹ The gap between them comes from what each analyst counts as a mental health app, which is the same ambiguity that later decides your regulatory path.

Growth forecasts are more consistent than the levels. Analysts model approximately 17.4 percent compound annual growth through 2034 and 2035, with published endpoints ranging from about $29 billion to $45 billion depending on the forecast year and the scope counted.³

Wellness app or regulated digital therapeutic?

This decision sets everything downstream, and it is driven by your claims rather than your features. A general wellness app supports mindfulness, mood logging or stress reduction without asserting that it prevents, manages or treats a specific condition. A digital therapeutic delivers a clinically evaluated intervention for a diagnosed condition. Once software carries a medical purpose it becomes software as a medical device, and treatment claims then require regulatory review before you can make them.

The line is not theoretical. As of mid-2025 the FDA had cleared 13 prescription digital therapeutics spanning mental health and metabolic indications, of which 12 addressed conditions including substance use disorder, insomnia, ADHD, PTSD, major depressive disorder, generalised anxiety disorder and postpartum depression. The one remaining clearance covered an indication outside mental health.⁴

Two clearances show what the bar looks like in practice. Rejoyn became the first FDA-cleared smartphone application for depression, cleared through the 510(k) pathway in 2024.⁵ DaylightRx was cleared on 04-Sep-2024 for generalised anxiety disorder in adults aged 22 and over, delivering cognitive behavioural therapy through interactive lessons.⁵ Both are prescription products with a defined indication and a defined age range, which is what a clearance actually buys: permission to make one specific claim to one specific population.

The useful discipline is to write your marketing copy in month one, then ask a regulatory adviser whether the product you are scoping is allowed to say it. Teams that do this in reverse either soften the copy at launch, losing the differentiation they built for, or ship a claim they cannot defend.

What clinical evidence should a mental health app have before launch?

Evidence is not binary. It comes in three tiers, and blurring them in marketing copy is the error that draws attention from regulators and app store reviewers alike.

Most consumer apps sit in the first row and write copy that implies the third. The phrases that get teams into trouble are the soft ones: clinically proven, therapist-designed, evidence-based. Only the middle term is descriptive rather than evaluative, and even that one commits you to naming the trial.

If you are pre-revenue, the sequence that holds up is narrow and boring. Pick one condition and one validated outcome measure. Run a pilot and describe it as uncontrolled. Publish it. Design the controlled study only once you know the intervention is deliverable. A single well-scoped trial on one indication is worth more commercially than broad claims across five, because payers, employers and clinicians all read the methods section.

Why HIPAA is the wrong compliance ceiling for a mental health app

Founders default to HIPAA as the standard to hit. Most consumer-facing mental health apps fall outside HIPAA altogether, because the developer is not a covered entity or the business associate of one, per HHS guidance.⁷ That does not reduce your obligations. It relocates them, to the FTC Health Breach Notification Rule, to state consumer health privacy statutes, to app store policy, and to GDPR wherever you have European users.

The execution record in this category is poor. In Mozilla’s review of 32 popular mental health and prayer apps, 28 carried a Privacy Not Included warning label and 25 failed the foundation’s minimum security standards.⁶

The choices that produce those labels are made at architecture time, not at policy-writing time. Which analytics SDK you embed. Whether an advertising identifier is readable by it. Whether mood logs and journal entries ever leave the device in identifiable form. What your data processing agreements permit a vendor to do with what you send. Mozilla’s repeated audits keep finding apps that fixed a finding and later regressed, which is the signature of a control living in a policy document rather than in the build pipeline.

Where your product does touch protected health information, typically because a licensed clinician delivers care inside it, the covered entity analysis changes and full HIPAA compliant app development applies. Decide which side of that line each data flow sits on, flow by flow, and write the answer down. A mixed product is normal. An undocumented mixed product is not defensible.

What happens when a user discloses suicidal ideation?

Answer this before you build the journalling feature. Any product that collects free text and mood data will eventually receive a disclosure of self-harm intent. The obligation to respond is a duty of care, and a product implements it through three components: detection, routing and documentation.

1. Detection. Language triggers on free text, thresholds on validated assessment instruments, and flags on rapid symptom deterioration. Tune these to over-trigger rather than under-trigger, and accept the false positive cost.
2. Routing. A defined path to a human or an accredited crisis line, localised to the user’s country, reachable in one tap from wherever the disclosure happened, and available at three in the morning when your support team is not.
3. Documentation. A timestamped record of what was detected, what the user was shown, and what happened next, retained to the same standard as the rest of the clinical record.

Treat this as release-blocking. App store reviewers ask for it, and its absence is among the fastest ways to fail review or to lose user trust permanently after one incident. If you use models to score risk in free text, the rule that governs any other applied AI deployment governs this one: log every decision with the model version that produced it, keep a human in the escalation path, and never let a classifier be the last step before a person in crisis is left alone.

Which features belong in the first release?

Start from where the money and the evidence already are. Consultation, meaning teletherapy delivered by a licensed clinician, held the largest revenue share of the mental health apps market in 2024, ahead of the self-management categories.⁹ That tells you where users will pay, and it also imports a heavier build: scheduling, clinician licensure by jurisdiction, practitioner tooling and secure video. You are building the wider telehealth stack rather than a content app, and the cost profile follows.

That usage skew has a design consequence and a research consequence. Your default interface, tone and recruitment channels will over-serve the group already most likely to arrive. If you later run a study on your own user base, the sample will not represent the population your marketing claims to serve, and a reviewer will say so.

Then there is the engagement trap. Streaks, daily push notifications and completion badges reliably lift daily active users, and for some conditions they work directly against the clinical goal. Pushing someone in a depressive episode to protect a streak converts a support tool into one more thing they have failed at.

Optimising a mental health app for daily active users optimises the one metric that can rise while the person using it gets worse.

Design the engagement model per condition, instrument outcomes rather than sessions, and let a user disengage when disengagement is the healthy choice. Monetisation follows the same logic. Subscriptions, employer and payer contracts, and clinician-side licensing keep the incentive pointed at outcomes. Advertising and data brokerage do not, and they are also the business model that produces the privacy findings above.

How to create a mental health app without expensive rework

The sequence below front-loads whatever is expensive to reverse. Most mental health app development schedules slip on the claim and the data model rather than on the code.

1. Claim decision. Write the treatment claim, the indication and the population in plain sentences. Take regulatory advice on whether that makes the product software as a medical device, before scoping anything.
2. Data architecture. Map every field a user produces to a destination, name every analytics and crash-reporting vendor, and decide what never leaves the device. Do this before choosing SDKs, because removing an SDK later is a re-release and a disclosure, not a config change.
3. Crisis protocol. Detection triggers, routing targets by country, escalation to a human, and the documentation record. Review it with a clinician, not only with counsel.
4. Core intervention. Build one intervention for one condition properly, instrumented with the outcome measure you intend to publish against.
5. Evidence. Run the pilot, describe it accurately, publish it, then design the controlled trial if you want to make an effect claim.
6. Scale. Additional conditions, teletherapy delivery, employer distribution, and the integrations each of those pulls in.

The order matters more than the calendar, which will move. Claims before architecture, data model before SDKs, crisis protocol before public beta, evidence before the effect claim. Teams that follow that order build the data layer once. Teams that invert it rebuild it while a reviewer waits and a lawyer rewrites the copy. If you are weighing a wellness route against a regulated one, talk to our team.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.