HIPAA-compliant app development, without the certification theater

There is no such thing as a HIPAA certification. There is a Privacy Rule, a Security Rule, a Breach Notification Rule, a signed BAA, and an architecture that can survive a hospital security review. We build the last of those, sign the BAA, and tell you in writing where our responsibility stops and your compliance counsel’s begins.

Illustration of a health record moving through segregated, audited systems

Two bad pitches, and the one we make instead

Health founders get offered two versions of this service. The first is an agency promising to “handle HIPAA compliance” — a claim no software vendor is qualified to make, since compliance is an organizational program, not a feature you can install. The second is a studio that refuses the project outright because one future feature might be regulated.

Our answer is the same one on our custom software page: we architect around the compliance boundary rather than through it. We build HIPAA-aware systems to the boundary your compliance counsel defines. We do not certify clinical safety, privacy, security or regulatory compliance — qualified specialists do that, and your scope says which ones and when.

That sentence loses us a small number of deals and has saved our clients more money than any feature we have ever shipped. The full version of it, including how we handle BAAs, encryption, access control, subprocessors and incident response, lives on our trust and security page.

Four failures we find in nearly every health app we inherit

None of these are encryption problems. Encryption is the part everyone remembers.

The analytics tag on the intake form

Encryption is rarely what fails. What fails is the marketing stack: a session-replay script recording an intake form, an ad pixel firing on a page whose URL contains the condition, an event payload carrying an email address into a tool with no agreement behind it. This has produced more health-data enforcement and litigation than stolen laptops ever did.

A vendor in the stack that will not sign

PHI does not stay in your database. It moves through your SMS provider, your email sender, your error monitor, your support desk, your transcription service. Every one of those needs an agreement, and several popular tools will not sign one at all — or only on a plan nobody budgeted for. The time to find out is architecture, not procurement.

No answer to “who read this record?”

The first question a hospital security reviewer asks is not about your cipher suite. It is whether you can produce, for a given patient and a given week, the list of accounts that viewed the record. Products that log writes but not reads cannot answer it, and retrofitting an audit trail into a mature schema is genuinely expensive.

Shared accounts and permanent access

One clinic login used by six front-desk staff. A contractor whose credentials still work eleven months after the engagement ended. A support tool where every agent can see every patient. None of this shows up in a demo, all of it shows up in a review, and the fix is unglamorous: unique identities, roles scoped to a job, automatic session expiry, and offboarding that actually revokes.

If you only act on one item from this page: audit what third-party scripts run on your authenticated screens. Open the network tab on your intake flow and read the outbound requests. Most teams find at least one they cannot justify, and it is the cheapest thing on this page to fix.

Work out whether HIPAA applies to you at all

A meaningful share of the founders who ask us for a HIPAA-compliant app do not need one. Telling them so costs us revenue and buys us a reputation, which is a trade we will make every time.

Covered entity

Providers, health plans, clearinghouses

HIPAA applies directly. Your software vendors become business associates, which means agreements, documented safeguards and a real answer when your compliance officer asks where the data lives.

Business associate

Software handling PHI on a covered entity's behalf

The most common position for a health-tech startup selling to clinics or systems. You inherit obligations by contract, and your own subprocessors need agreements flowing down from yours.

Neither

Direct-to-consumer wellness and fitness apps

Usually outside HIPAA entirely — which does not mean unregulated. Consumer health-data rules, state privacy laws, app-store health-data policies and platform permission requirements still bind you, and users do not distinguish between regimes when their data leaks.

Being outside HIPAA is not the same as being unregulated — consumer health-data rules, state privacy statutes and platform policies still apply, and the specific set depends on where your users are and what you collect. If your product is a consumer wellness app, start at wellness app development instead and bring the regulatory question to a specialist rather than a developer.

Seven things we do differently when PHI is in scope

This is engineering practice, not paperwork. Each item exists because skipping it is expensive to reverse once the product has users.

01

Data inventory before schema

Every field, classified: identifier, clinical, financial, operational, derived. What is collected, why, who can see it, how long it is kept, and what happens when a user asks for deletion. This document is boring, takes two days, and prevents the architecture mistake that costs six figures later.

02

Segregation of the regulated core

PHI is confined to a defined set of services and stores rather than sprayed across the product. That is what makes a scope statement possible, keeps the audit surface small, and lets the marketing site, the content, and the unauthenticated funnel move at normal speed without dragging a compliance review behind them.

03

Identity, roles and session discipline

Unique accounts per human, roles that mirror actual jobs rather than org-chart titles, least privilege by default, automatic logoff, and an offboarding path that revokes rather than deactivates. Break-glass access exists, is logged loudly, and is reviewed.

04

Audit logging as a product feature

Reads as well as writes, attributable to a person, queryable by patient and by date, retained for the period your policy requires, and shipped somewhere an attacker with database access cannot quietly edit. We treat an unlogged read of patient data as a defect, not a nice-to-have.

05

Encryption, and the parts encryption does not solve

TLS in transit, platform encryption at rest, and application-level encryption on the fields whose exposure would actually hurt. Then the harder work: keys nobody keeps in a repo, backups that are as protected as production, and non-production environments that never contain real records.

06

The vendor and subprocessor map

A written list of every third party that can see PHI, what each one receives, and whether an agreement is in place. Anything without a signed agreement either gets removed from the PHI path or gets replaced. We would rather lose an analytics tool than a client's contract.

07

Breach response you can rehearse

A named human, an escalation path, a clock, a containment step, and a template. Notification deadlines are set by regulation and by your own contracts, so the plan is written against those rather than against optimism. Suspected exposure of client or patient data gets escalated to your named contact within one business day of detection.

We built the State of New Hampshire’s immunization platform with HL7 integration and 50+ schools live. We built Previa, which automates prior authorization against payer APIs including Humana and UnitedHealthcare and cut processing time by 75%. Patient Talker was built HIPAA-conscious with end-to-end encryption and went through third-party security assessment before release. Those are the engagements to ask us about on a call.

Read the case studies

What a HIPAA-aware build actually costs

Fixed prices, real deadlines, no hourly billing. Compliance-aware architecture is not a surcharge on this list — it is how the work is done when PHI is in scope.

EngagementPriceTimelineWhat it is
Healthcare / mental-health prototypefrom $3,500Scoped per buildClickable or coded, on synthetic non-sensitive data. No PHI, no BAA needed, enough to test with users and show investors.
Healthtech & Mental Health MVP Blueprint$1,9997 daysThe planning sprint plus intended-use boundary, sensitive-data and claims inventory, clinical dependency map and specialist decision points.
MVP Planning Sprint$1,5005 daysScope, backlog, roadmap, architecture options and a real build estimate. Credited in full toward the build.
MVP buildfrom $12,000Scoped in the sprintA bounded version one in production, with the regulated core segregated from day one.
Full custom buildfrom $25,000Scoped per buildFor funded startups and organizations replacing off-the-shelf clinical tooling.
App / Product Rescuefrom $2,50010 daysTechnical assessment of an existing app plus a prioritized fix plan — the usual route through a failed hospital security review.
QA & Release Readiness$9997 daysTest strategy, critical journeys, device matrix, defect report and a written go/no-go recommendation.
App maintenance retainerfrom $1,000/moOngoingMonitoring, fixes, dependency updates and releases. Compliance posture decays without this more than founders expect.

What none of these buy: a certification. We build HIPAA-aware systems; we do not issue legal sign-off. Every price on the site sits on one page if you want to compare.

See all pricing

Twelve items to work through before your first security review

Take this list and run it yourself, with us or with another team. It is the same one we work through internally, and it is genuinely more useful to you than a sales call.

1

Establish which regime you are actually in — covered entity, business associate, or neither — in writing, before the first schema decision.

2

Write the data inventory: every field, its classification, its retention, and who can read it.

3

List every vendor that can see PHI and confirm each will sign a BAA. Remove or replace the ones that will not.

4

Remove third-party tags from authenticated screens, intake forms and any URL whose path reveals a condition.

5

Give every human a unique account, scope roles to real jobs, and set automatic session expiry.

6

Log reads as well as writes, attributable and queryable by patient.

7

Encrypt in transit and at rest, and add field-level encryption where exposure would genuinely harm someone.

8

Confirm non-production environments contain synthetic data only, and that backups are protected like production.

9

Write the breach response plan: named owner, escalation path, containment step, notification clock.

10

Document a risk analysis, schedule its review, and keep it yours rather than your vendor's.

11

Train the workforce and, more importantly, build an offboarding step that actually revokes access.

12

Decide who owns the intended-use statement, and whether it needs regulatory counsel.

Deadlines for risk analysis cadence, breach notification and workforce training are set by regulation and by your own contracts, and both change. Check the current HHS guidance and your BAAs rather than any agency’s blog post, including this one.

What we do not certify

  • We build HIPAA-aware systems. We do not issue HIPAA certifications — no such certification exists — and we are not a substitute for your compliance counsel.
  • We map intended-use boundaries, sensitive-data inventories and clinical dependencies during planning. We do not provide regulatory or legal sign-off.
  • We do not determine whether your product is a regulated medical device. We would rather raise that question in week one than at submission.
  • We are not a clinical provider. Products we build do not deliver medical advice on our authority.

Security questionnaires

Available before contracting, along with a subprocessor list and architecture documentation for the proposed build.

Draft BAA

Ask and we will send it. Reviewing it early is a much better use of a week than discovering a disagreement at signature.

Incident escalation

Suspected exposure goes to your named contact within one business day, with what is known, what is not, and the containment step already taken.

Before the security review

Are you HIPAA certified?

No, and neither is anyone else — HHS does not certify software, developers or agencies, so there is no certificate to hold. Any vendor showing you a HIPAA certification badge is showing you a training-company logo, not a government credential. What we do offer is concrete: we sign a BAA, we build to the Privacy, Security and Breach Notification rules, we map PHI before we write a schema, and we put the boundary of our responsibility in the statement of work. Our full position is on the trust page.

How much does HIPAA-compliant app development cost?

The compliance-aware architecture is not a separate line item — it is how the build is done. A healthcare prototype on synthetic data starts at $3,500. A Healthtech & Mental Health MVP Blueprint, which includes the sensitive-data and claims inventory, is $1,999 over 7 days. MVP builds start at $12,000 and full custom builds at $25,000. What HIPAA adds to a project is not usually cost, it is scope discipline: features that touch PHI get gated, and the ones that do not get shipped first.

Does HIPAA even apply to my app?

Often it does not, and that is worth an hour of your time before it costs you a quarter of your budget. HIPAA reaches covered entities — providers, plans, clearinghouses — and the business associates handling PHI on their behalf. A direct-to-consumer wellness app with no provider or payer relationship is usually outside HIPAA, though other regimes such as the FTC's health-data rules and state privacy laws can still apply. We map which regime you are actually in during planning, and we tell you when the honest answer is that you need a specialist rather than a developer.

Will you sign a BAA?

Yes, where the engagement puts us in contact with PHI on behalf of a covered entity or another business associate. It gets signed before anyone on our side touches an environment containing real patient data, not at kickoff and not retroactively. Prototypes run on synthetic data by default, which means a large share of early-stage work never needs a BAA at all.

Can we use Firebase, Mixpanel or the Meta pixel in a HIPAA app?

Some of these, sometimes, in some places — and this is the question that has cost health companies the most money in the last few years. The rule of thumb we build to: no third-party tag runs on an authenticated screen, an intake form or any URL whose path itself reveals a condition, unless that vendor has signed a BAA and the integration has been configured to exclude identifiers. Marketing pages, yes. Symptom-checker result pages, no.

We already have an app that a hospital's security team is reviewing. Can you help?

That is what the App Rescue engagement is for: $2,500 over 10 days buys a full technical assessment, a prioritized findings list and a fix plan you can hand to the reviewer. Most failed security reviews we see are not exotic — missing audit trails, shared admin accounts, PHI in logs, a subprocessor with no agreement in place. Those are fixable without a rewrite.

Who decides whether our product is a regulated medical device?

Not us, and we will say so early rather than late. Software that measures, diagnoses or drives treatment decisions can fall under FDA oversight, and where that line sits for your specific intended-use statement is a question for regulatory counsel. What we do is force the intended-use statement to exist in week one, so the question gets asked while it is still cheap to answer.

Not sure which engagement fits? Start with the MVP Planning Sprint or Healthtech Blueprint — both are credited toward a build, and both end with a scope you can take to any developer.

Where a compliant build usually goes next

Bring us the security questionnaire

Tell us who your buyer is, what data the product touches, and what deadline you are working to. We will come back with the scope, the price and the parts we would send to a specialist instead.