Somebody types "I don't think I can keep doing this" into your app at 2:47 in the morning. What happens next is not a phase-two feature. It is the first thing your architecture decides, usually by accident and usually badly — a message queued for a therapist who reads it at 9 a.m., a chatbot replying with a breathing exercise, or nothing at all.
That is why costing therapy app development is different from costing a fitness app. The build is not exotic. The decisions around it — who is clinically responsible, which regulatory regime you are in, what happens when the product encounters distress — are what move the number, the timeline and the risk. This page covers what the different kinds of therapy app cost, what you should refuse to build, and how the crisis path is designed as an engineering problem.
"Therapy app" is four different products with four different price tags
Founders say "therapy app" and mean one of these. They do not cost the same or carry the same risk.
| Product | What it is | Where cost concentrates | Regulatory weight |
|---|---|---|---|
| Directory and booking | Clients find a therapist and book a session | Search, matching, calendar, payments | Lightest — you are a marketplace, not a provider |
| Teletherapy delivery | Sessions actually happen in your product | Video, secure messaging, notes, billing | Heavy — PHI, BAAs, provider workflow |
| Self-guided / structured programs | Exercises, journaling, psychoeducation, mood tracking | Content pipeline, engagement mechanics | Medium — claims and crisis handling |
| AI-assisted conversation | A model talks to users about how they feel | Guardrails, escalation, transcript review, evaluation | Heaviest, and changing fastest |
The most expensive mistake in this category is scoping product two while describing product one to your developer. A booking marketplace is a modest build. The moment sessions happen inside your product you have acquired a provider workflow, a notes system, a video vendor, a business associate agreement chain and a support burden — a different budget entirely.
What it costs
Zee Palm publishes fixed prices, so here is the arithmetic rather than a range.
- Healthtech & Mental Health MVP Blueprint — $1,999, 7 days. Intended-use boundary, sensitive-data and claims inventory, crisis and clinical dependency map, architecture options and a real estimate. Not an upsell — it is how you avoid discovering in week eight that the crisis decision changes the data model.
- Prototype on synthetic data — from $3,500. No real client data, no BAA needed. Enough to put the crisis flow in front of actual clinicians and find out the copy is wrong.
- MVP build — from $12,000. A directory-and-booking product, or a bounded self-guided program, on one platform.
- Full custom build — from $25,000. Where real teletherapy delivery starts: video, secure messaging, provider workflow, notes, admin.
- QA & Release Readiness — $999, 7 days. Critical-journey and crisis-path testing, device matrix, store metadata and claims review, written go/no-go.
- App maintenance — from $1,000/mo. Not optional here. A crisis resource list that goes stale is a live safety issue.
Full list on the pricing page. What none of those numbers buy: clinical content, a regulatory opinion, or a certification.
The unprofitable advice: most early therapist networks do not need a custom build. An established practice-management platform — scheduling, HIPAA-eligible video, notes and billing already solved — plus a decent website and booking flow will serve fifty clinicians better than a custom version one that reimplements 15% of it. Build custom when the workflow itself is your product. If your differentiator is your therapists, spend the money on therapists.
Buy the video. Always.
Real-time video is the most reliably underestimated line item in teletherapy: echo cancellation, network adaptation, reconnection when a phone switches from Wi-Fi to cellular mid-session, TURN servers for restrictive corporate networks, and a waiting room that does not leak who is in it. Teams that build it themselves spend a quarter and ship something worse than a vendor's free tier. Use an established video API, and check three things before signing:
- The BAA is usually tied to a plan tier. Free and entry plans frequently do not include one. Confirm in writing which SKU carries it before you build against the SDK.
- Recording changes everything. Recorded sessions are a new class of PHI with retention, access-control, consent and deletion obligations. Most early products should not record.
- Session metadata is still PHI-adjacent. Who met whom, when, for how long — inside the same protections as the clinical record, not in a general analytics tool.
Same logic for scheduling, payments and e-signature. Buy them. Build only what encodes your model of care.
The compliance boundary, stated plainly
Two questions decide your regulatory posture, and they have different answers than founders expect.
Are you a covered entity, a business associate, or neither? If licensed clinicians deliver care through your platform, or you serve a provider organization or health plan, you are almost certainly handling PHI as a business associate — and every downstream vendor touching that data needs a BAA too: hosting, database, video, email, error monitoring, analytics, AI providers. A direct-to-consumer self-help product often sits outside HIPAA entirely, which people misread as "unregulated". Consumer health-data statutes, state privacy law, app-store policy and consumer-protection rules about claims all still apply.
What is your intended use? The distance between "a tool for reflection" and "treats depression" is the distance between a consumer app and a potentially regulated medical device. Regulatory counsel makes that determination, not your engineers and not us. What we do is force the question into week one and write the answer into the statement of work. The engineering side is covered in how to build a HIPAA-compliant app and on the HIPAA-compliant app development page.
To be exact: Zee Palm builds HIPAA-aware, compliance-conscious systems and maps sensitive-data, claims and clinical boundaries during planning. We do not issue certifications or legal sign-off, and we do not determine whether your product is a regulated medical device. There is no such thing as a HIPAA certification, and a vendor who offers one has told you something useful about themselves. Our trust page says the same.
Where the law is moving on AI in behavioral health
This is not legal advice. It is a map of the questions, and the area moves fast enough that anything specific should be re-checked with counsel before you build on it. Several US states have legislated on AI in mental health and more are moving. The categories below stay stable even as the statutes change; the specifics are exactly where you should not trust a blog post.
1. Scope of practice. Can software do what a licensed professional does, and under what supervision? The emerging pattern: AI may not present itself as or substitute for a licensed clinician, and diagnosis, treatment planning and therapeutic intervention stay with licensed humans. Architectural consequence: a hard-coded refusal set enforced outside the prompt, plus a named clinical owner who defines it and signs off on changes.
2. Disclosure. Must the user be told they are talking to software, how prominently, how often? Architectural consequence: disclosure is a UI requirement with persistence rules, not a line in the terms — at session start, on re-entry, and visibly during the conversation. Log that it was shown.
3. Crisis-handling duties. What must the product do when a user indicates risk of harm? Architectural consequence: deterministic escalation, covered next. This is the category that most often becomes a legal obligation rather than a design preference.
4. Data protection. Mental health data attracts specific treatment under several state consumer health-data laws, often with consent, deletion and non-sale requirements stricter than general privacy law. Architectural consequence: granular consent capture, a real deletion path, and a data inventory that answers "what do you hold on me" without an engineer running a query.
5. Claims and advertising. Your App Store listing is a regulated surface. Most rejections and most complaints in this category come from marketing copy, not code.
6. Licensure and location. Where a human clinician is involved, care is generally governed by where the client is, not the therapist. If you match across state lines, licensure routing is a product requirement — a filter in your matching logic and a hard block in your booking flow. Interstate compacts exist for some professions and change what is possible.
The practical version: assume disclosure, crisis handling and data protection will be required of you somewhere you operate, and build as if they already are. Retrofitting is expensive.
Crisis escalation is an engineering problem
This is where a builder genuinely adds value, because most of what goes wrong is not clinical subtlety — it is software failing in ordinary, preventable ways. Your clinical lead defines what should happen; the rest is how it gets built so it actually happens.
Detection is layered, and the layers have different jobs.
- A user-initiated affordance — a help control always present, never paywalled, never more than one tap away, reachable when the user is logged out or offline. Highest signal, lowest false-positive rate, and the layer most products bury.
- Structured signals — a screening instrument scored client-side, a self-report field, rapid deterioration in tracked scores. Deterministic, testable, auditable.
- Text signals — keyword or classifier detection on free text and chat. Useful, noisy, never the only layer.
Escalation must be deterministic, not model-decided. If a language model is in the loop, its job is to raise a flag, not to decide the response. The flag routes into code that executes a fixed sequence your clinical lead wrote. A model that can be talked out of escalating will be talked out of escalating — users in distress are sometimes extremely articulate about not wanting help. Put escalation behind a function call the model can trigger but not suppress, and make the escalated state the fallback.
Resources are configuration, not constants. Crisis line numbers are locale-dependent and they change. A US hotline shown to a user in Manchester or Melbourne looks like help and is not. Keep them in remotely-updatable configuration, resolve by the user's actual locale rather than device language, and cache them on-device so they render with no network — which is a large part of why ongoing maintenance is not optional here.
Design the failure states, because they are the whole point.
- Escalation attempted with no connectivity: the user sees a cached number, not a spinner.
- Handoff to a queue that is unstaffed at 3 a.m.: either the coverage exists and you say so plainly, or the copy changes. Never imply coverage you do not have.
- The escalation call fails: it raises an alarm to a real person rather than logging a warning.
- The user closes the app mid-escalation: decide in advance whether anything follows, and who owns it.
Test it like a safety system. A written red-team phrase set — direct, oblique, metaphorical, multilingual and adversarial ("hypothetically", "for a story", "asking for a friend") — run against every release, reviewed by your clinical lead rather than by QA alone. Track false negatives ruthlessly, and false positives too: an over-triggering system trains users to dismiss it.
Log everything, and treat the logs as clinical records. Every detection, escalation, resource shown and handoff, timestamped — not for analytics, but for the review after a bad outcome and the governance function that should read them monthly.
None of that is exotic engineering. It is ordinary engineering applied to something that matters, which is exactly what does not happen when the crisis path is scoped last. That is why the mental health app development page scopes it first.
What we would cut from version one
Insurance billing and claims. Group sessions. A custom EHR. E-prescribing, which carries its own regulatory surface. A simultaneous web, iOS and Android launch. Employer outcome dashboards, until you have an employer. AI that talks to users, until the boundary above is settled and someone clinical owns it.
What we would not cut: the crisis path, the notes editor if clinicians use your product (one that loses work is how you lose your supply side), calendar sync that does not double-book, and real-device QA.
If you want the boundary written down before you spend build money, the $1,999 blueprint takes seven days. If you already know what you are building, send us the scope.
Frequently asked questions
How much does it cost to develop a therapy app?
A directory-and-booking product or a bounded self-guided program fits the $12,000+ MVP band on one platform. A teletherapy delivery platform — video, secure messaging, provider workflow, notes, admin — starts around $25,000. Add a $1,999 blueprint first and $1,000+/month maintenance after.
Does a therapy app have to be HIPAA compliant?
It depends on who you serve. If licensed clinicians deliver care through your platform, or you contract with a provider organization or health plan, you are handling PHI and need BAAs across every vendor that touches it. A direct-to-consumer self-help product often falls outside HIPAA while remaining subject to consumer health-data laws, state privacy statutes and app-store policy. Get the determination from counsel, not a developer.
Can we build an AI therapist?
You can build conversational software. Whether it may behave like a therapist is a legal and clinical question, and several US states have legislated on it recently with more expected. Build for disclosure that the user is not talking to a human, refusal rules enforced in code rather than in the prompt, deterministic escalation the model cannot suppress, and transcript review tooling — then have your intended use reviewed by counsel before launch.
What happens if a user is in crisis?
Whatever your product was built to do, which is why it gets designed first. In practice: a help affordance that works offline and is never paywalled, layered detection, a fixed escalation sequence written by a clinical owner and executed in code, locale-correct resources in maintained configuration, alarms on failed handoffs, and audit logs someone reads. Clinical responsibility sits with your clinicians; correct implementation of their specification sits with your builder.
Should we build or buy a teletherapy platform?
Buy, unless your workflow is your product. Established practice-management platforms already solve scheduling, HIPAA-eligible video, notes and billing, and will serve a growing therapist network better than an early custom build. Build when you have an unusual matching model, a payer integration, or a program structure nobody sells off the shelf.
Will Apple or Google reject a mental health app?
Rejections here usually trace to claims rather than code — a listing implying treatment of a diagnosed condition, screenshots showing clinical outcomes, missing crisis resources, or a safety feature behind a paywall. Treat the listing copy as a regulated surface your clinical lead signs off.