Mental Health App Development: Privacy, Crisis Flows and Clinical Review

A mental health app needs four feature sets (journaling, mood tracking, therapist booking and messaging, and content programmes) plus two things teams leave too late: a crisis flow that signposts local helplines, such as 988 in the US, and privacy rules stricter than an ordinary app. A first web or PWA version fits a 4–6 week fixed scope. RAITHub builds web apps and PWAs, not native apps.

If you would rather have it built for you, see how RAITHub would build this below.

One point before the detail. RAITHub is a software studio, not a clinical provider. It does not give clinical advice, decide what is safe to say to someone in distress, or hold any health licence. What follows is engineering guidance: how to build the software so that your clinical lead's decisions are enforced consistently. RAITHub has not shipped a mental health product; its health-adjacent client work is a healthcare scheduling app, which is not a regulated product.

What features does a mental health app need?

Four feature sets cover most products in this space. Which ones you need depends on whether you are a self-help product, a therapy marketplace, or a provider giving existing clients a digital front door.

Feature set	What it does	Engineering detail that matters
Journaling	Free-text entries, optional prompts, private by default	Encrypt entries at rest, keep them out of analytics and logs, and never send their text to a third-party service the user did not agree to
Mood tracking	Daily check-ins on a scale, tags, trends over time	Store the scale version with each answer, so a change of scale does not corrupt history; charts must not imply a diagnosis
Therapist booking and messaging	Availability, booking, reminders, secure messages, video links	Double-booking prevention in the database, reminders that reveal nothing sensitive, and clear service hours on messaging so no one expects a crisis reply
Content programmes	Courses, exercises, audio and articles, unlocked over time	Every item carries a clinical reviewer, a review date and a version; unreviewed content cannot be published

Two parts sit across all four: the crisis flow and the privacy model. They are covered next, because they change the design of everything above.

Can a mental health app be a web app instead of a native app?

Yes, for most of the features above. A progressive web app (PWA) is a website that can be installed to the home screen, work partly offline and, on current browsers, send push notifications. Journaling, mood check-ins, booking, messaging and content all work well as a PWA. Native apps still make sense if you need deep device features or a presence in the app stores from day one. RAITHub does not build native mobile apps; if your plan depends on one, you need a different team for that part.

How should a mental health app handle a user in crisis?

With a crisis flow designed before any other feature: clear signposting to local helplines, written escalation rules signed off by your clinical lead, and software that shows help every time it is unsure, instead of trying to judge risk on its own.

Signpost local helplines, by region

Show helplines for the user's country, reachable from every screen in one tap, not buried in settings. In the US, the 988 Suicide & Crisis Lifeline can be reached by call, text or chat, 24/7, and describes itself as free and confidential. In the UK and Ireland, Samaritans answer 116 123, free, day or night. Every other market needs its own list, checked by someone local, plus the local emergency number. Treat this list as content with an owner and a review date: a wrong number is a safety defect.

Write the escalation rules down

Decide, with your clinical lead, what happens in each case:

• What counts as a risk signal. Usually a self-report answer (a check-in option such as "I am thinking about hurting myself"), a clinically reviewed list of phrases in journal or chat text, or a message to a therapist.
• What the user sees. A crisis panel with helplines, shown immediately, which the user cannot accidentally dismiss without seeing.
• Who is told. If the user is in a care programme and has consented, which clinician is alerted, by what channel, and what happens out of hours.
• What the app must not do. Promise a reply it cannot guarantee, or keep the user in a chatbot conversation instead of pointing them to people.

Messaging needs the same care: show service hours on every thread and say plainly that it is not monitored for emergencies, with the helpline panel beside it.

Why AI must not give clinical advice

Large language models can be useful for summarising a user's own journal for them, or for searching approved content. They should not diagnose, recommend treatment, or respond to a crisis message with generated text. Route any risk signal away from the model to the crisis panel, restrict the model to retrieval over clinically reviewed content, and test those rules on every release. The LLM guardrails guide covers the technical controls.

What does a crisis escalation rule look like in code?

A minimal TypeScript sketch. It assumes the risk level has already been set by a clinically defined rule; the code's job is to make the response consistent, deny the AI a reply, and leave an audit record. It is illustrative, not production code, and not a risk-assessment tool.

// crisis-escalation.ts
type RiskLevel = 'none' | 'concern' | 'urgent'
type Region = 'US' | 'GB' | 'IE' | 'OTHER'
type Helpline = { label: string; contact: string }

// Owned by your clinical lead; reviewed on a schedule like any other content.
const HELPLINES: Record<Region, Helpline[]> = {
  US: [{ label: '988 Suicide & Crisis Lifeline', contact: 'Call or text 988' }],
  GB: [{ label: 'Samaritans', contact: 'Call 116 123' }],
  IE: [{ label: 'Samaritans', contact: 'Call 116 123' }],
  OTHER: [{ label: 'Emergency services', contact: 'Call your local emergency number' }],
}

type User = { id: string; region: Region; inCareProgramme: boolean; careTeamAlertConsent: boolean }

type Escalation = {
  showCrisisPanel: boolean
  helplines: Helpline[]
  notifyCareTeam: boolean
  allowAiReply: boolean
}

export function escalate(level: RiskLevel, user: User): Escalation {
  const helplines = HELPLINES[user.region] ?? HELPLINES.OTHER
  if (level === 'none') {
    return { showCrisisPanel: false, helplines, notifyCareTeam: false, allowAiReply: true }
  }
  // Any signal at all: show help, and never let a model answer.
  return {
    showCrisisPanel: true,
    helplines,
    notifyCareTeam: level === 'urgent' && user.inCareProgramme && user.careTeamAlertConsent,
    allowAiReply: false,
  }
}

// Append-only audit row: no journal text, only the fact and the outcome.
export function auditRow(level: RiskLevel, user: User, result: Escalation, source: string) {
  return {
    userId: user.id,
    event: 'risk_signal',
    level,
    source, // e.g. 'checkin_q3' or 'phrase_list_v12'
    crisisPanelShown: result.showCrisisPanel,
    careTeamNotified: result.notifyCareTeam,
    at: new Date().toISOString(),
  }
}

Three choices are deliberate. Any level above none shows the panel, so uncertainty fails towards help. The model never answers once a signal fires. And the audit row records which rule fired and what happened, without copying the user's words into a log. Write a test for every branch, including an unknown region. The audit log design guide covers storing those rows.

Who reviews the content in a mental health app?

A qualified clinician you appoint, not the developers. The software's job is to make that review impossible to skip:

• Every exercise, article, programme step, crisis message and push notification has a status (draft, in review, approved, retired), a named reviewer and a review date.
• Only approved items can be published; editing an approved item creates a new version that goes back to review.
• Items past their review date are flagged, and helpline lists have the shortest cycle of all.
• Copy the app generates, such as weekly mood summaries, uses templates that were reviewed, not free text.

If the app claims to diagnose or treat a condition, it may be a medical device. The US FDA's page on device software functions says it intends to exercise enforcement discretion for software that helps users self-manage a condition "without providing specific treatment suggestions". Where your product sits is a regulatory question for your adviser.

What privacy rules apply to a mental health app?

It depends on who you are and where your users are, and the answer is a question for your privacy counsel. Two points come up in almost every project.

US: the FTC Health Breach Notification Rule

Many consumer health apps are not covered by HIPAA. The FTC's guidance on its Health Breach Notification Rule says the rule can apply to vendors of personal health records, including health apps, and that a breach "is not limited to cybersecurity intrusions": sharing covered information without the user's authorisation can trigger notification duties. Notices to individuals are due within 60 calendar days of discovery, and the same page gives civil penalties of up to $53,088 per violation. In 2023 the FTC announced that BetterHelp would pay $7.8 million after sharing health information with advertising platforms. In engineering terms: no advertising pixels on screens that reveal health status, and every third-party script reviewed.

EU and UK: special-category data under GDPR

Article 9 of the GDPR treats "data concerning health" as a special category whose processing is prohibited unless an exception applies, such as explicit consent for specified purposes. Mood scores and journal entries are very likely to count. Store consent as versioned events, keep data minimal, and let users export and delete their data.

General information, not legal or medical advice. Whether HIPAA, the FTC rule, the GDPR or a medical-device regime applies depends on your business model and markets. Confirm with your adviser.

On RAITHub's side: RAITHub signs NDAs and DPAs and works inside your controls. Production and user health data stay in your own covered cloud account, and development uses synthetic data. RAITHub holds no HIPAA, SOC 2 or ISO certification and signs no BAAs.

Buy, build or hire: which is right for a mental health app?

Option	Example and cost	Choose this when	Watch out for
Off-the-shelf practice software	SimplePractice: solo plans listed at $49, $79 and $99 a month when we checked	You are a therapist or practice that needs booking, notes and a client portal, not a product of your own	You configure their product; you cannot add your own programmes, crisis rules or brand experience
No-code builder	Bubble: paid plans from $59 a month on annual billing when we checked	You want to test demand for a self-help concept with non-sensitive data and few users	Check the vendor's terms for health data and where it is stored before any real user signs up
Custom web app or PWA	Market rates vary; try the MVP cost estimator	Your product is the programme, the crisis flow and the data model, and you need control of each	You own security, testing and clinical review processes; budget for them

Many teams start with practice software for therapist-side work and build only the user-facing product. That split is usually cheaper and safer than rebuilding scheduling and notes.

Why RAITHub for this

For the engineering, with your clinical lead and privacy counsel owning the rules. RAITHub is a founder-led software studio, founded in 2024 in Dhaka, Bangladesh, working with clients worldwide in English. The evidence it can offer:

• Health-adjacent client work, stated plainly. RAITHub has built a healthcare scheduling app among 8 client projects. It is not a regulated product. The health software guide and the HealthTech page say the same.
• AI with guardrails. PadhAI, an AI tutoring platform RAITHub built, uses a 70/20/10 LLM router, retrieval over approved material (RAG) and math verification across 11 services. The same pattern of restricting a model to reviewed content applies here.
• Permissions and audit trails. Sundor Skin has 88 permission codes, 12 staff roles and row-level security across 146 PostgreSQL tables, with 530+ tests. Separating what a user, a therapist and a content reviewer can see is the same problem.
• Several audiences on one platform. TheSkinProof, the founder's own venture rather than a client, runs 5 portals on 217 API endpoints with 750+ tests.
• Working hours. US teams get a daily 2-hour evening overlap (Dhaka 19:00–21:00, New York 08:00–10:00 in winter); UK teams get 3 hours in winter and 4 in summer on a 9:00–18:00 day, with written daily handoffs.

When you don't need us

• You are a practice, not a product. Practice software already does booking, notes and a portal.
• You need a native app in the stores from day one. RAITHub builds web apps and PWAs only.
• You want the developer to decide what is clinically safe. RAITHub implements your clinical lead's rules; it does not write them.
• You need a vendor that signs a BAA or holds certifications. RAITHub does neither.
• You have no clinical lead yet. Appoint one first; without them the crisis flow and content review have no owner.

How RAITHub would build this

• Scope: a web app or PWA with mood check-ins and private journaling, encrypted at rest.
• Safety first: a region-aware crisis panel and escalation rules from your clinical lead, with tests on every branch and an audit trail.
• Therapist side: booking with database-level double-booking prevention, secure messaging with service hours, and reminders that reveal nothing sensitive.
• Content workflow: programmes with draft, review and approval states, named reviewers and review dates.
• Privacy: no ad pixels on health screens, consent stored as versioned events, export and deletion.

Timeline: 4–6 weeks for a fixed-scope first version of the MVP; larger programmes or an AI layer usually follow as a second phase. Clinical review runs on your team's calendar, so plan for it.

What you receive: automated tests and CI, handover docs and runbooks, and full IP under NDA. Production stays in your own cloud account; development uses synthetic data.

Next step: book the free 15-minute technical audit, then get a written fixed quote. Please do not send real user or patient data in the first message.

Frequently asked questions

How long does it take to build a mental health app?

A fixed-scope first web or PWA version with check-ins, journaling, booking and a crisis flow can fit 4–6 weeks of engineering. Clinical review of content and crisis rules runs on your clinical team's schedule and often sets the real launch date.

Does a mental health app need to be HIPAA compliant?

Only if you are a HIPAA covered entity or business associate. Many consumer apps are not, but the FTC Health Breach Notification Rule may still apply to them. Confirm with your adviser.

What should a mental health app do if a user is in crisis?

Show local helplines immediately, such as 988 in the US or Samaritans on 116 123 in the UK and Ireland, follow escalation rules your clinical lead has signed off, and never let an AI reply in place of a person.

Can AI chatbots be used in a mental health app?

For narrow tasks such as searching reviewed content or summarising a user's own entries, with guardrails. Not for diagnosis, treatment advice or crisis responses. Any risk signal should route to the crisis panel instead of the model.

Can RAITHub build a native iOS or Android mental health app?

No. RAITHub builds web apps and PWAs, which can be installed to the home screen and send notifications on current browsers. If you need a native app, use a mobile specialist for that part.

Is RAITHub a clinical provider?

No. RAITHub is a software studio. It builds the software that enforces your clinical lead's rules and gives no clinical, legal or medical advice.