Taking a vibe-coded health app to production: the HIPAA + App Store checklist

You built a working health app in a weekend. Lovable, Cursor, Replit, v0 — whatever you used, the demo works, the screens look right, and you can show it to a clinician without flinching. That part is genuinely impressive, and not long ago it would have taken a small team a month.

Then the first real question lands. A pilot partner asks for your HIPAA posture. Apple bounces your build. A friendly security person asks where the patient data actually lives. And the prototype that took a weekend suddenly needs months it doesn't have. This is the gap between built and shippable — and in healthcare, the gap is wider and the stakes are higher than anywhere else. This playbook is the checklist we walk founders through when they bring us a vibe-coded health app to make production-ready.

Three kinds of "done"

The single most useful mental model here is that there are three different finish lines, and AI tools only get you across the first.

Demo-complete means the happy path works on your machine, for one user, with fake data. This is where vibe coding shines and where most prototypes stop.

Production-complete means it survives real users: concurrency, bad input, dropped connections, data that must not be lost or corrupted, and errors that fail safely instead of silently. A prototype that loses one record in a thousand is fine in a demo and unacceptable in a clinic.

Compliance-complete means it's defensible: encryption, audit trails, access controls, signed agreements with every vendor that touches patient data, and the documentation to prove all of it. This is the finish line that closes pilots and unblocks fundraising.

The trap is assuming these are the same line, or that the distance between them is small. It isn't. A health app that's demo-complete is often 60–80% of the visible work and 20% of the total work. The rest is the unglamorous middle nobody screenshots. Naming the three finish lines up front keeps you honest about how much is actually left.

HIPAA is an architecture, not a feature

The most expensive misunderstanding we see is treating HIPAA as a checkbox you tick before launch. It isn't a feature. It's a property of how the whole system is built, and the Security Rule spells out three categories of safeguards you have to satisfy.

Technical safeguards are the ones engineers think of first: encryption of protected health information (PHI) at rest and in transit, access controls so each user sees only what they should, immutable audit logs of who accessed what and when, and integrity and transmission controls. Miss one and you're not compliant, even if the code looks airtight.

Physical and administrative safeguards are the ones engineers forget: documented policies, workforce training, an incident-response plan, and risk assessments. You can have flawless encryption and still fail an audit because there's no written procedure for what happens when a laptop is stolen.

The reason this matters for vibe-coded apps specifically: AI code generators optimize for a working screen, not for these properties. They rarely emit audit logging unprompted, routinely store data without field-level encryption unless you ask precisely, and never — by definition — sign a legal agreement on your behalf. The output passes a demo and fails an audit in minutes. We go deeper on the architecture side in our guide to HIPAA-compliant app development, but the headline is: design it in, or pay to retrofit it later at several times the cost.

Audit your own code first

Before you talk to anyone, run this checklist against your own codebase. You can do most of it in an afternoon, and it tells you how deep the hole is.

• Where does PHI live, exactly? List every table, bucket, log, and third-party service that stores or receives patient data. Most founders discover PHI in at least one place they forgot about — an analytics tool, an error tracker, a logging pipeline.
• Is it encrypted at rest and in transit? TLS 1.2+ everywhere, and encryption on the database and any file storage. "The cloud encrypts it by default" is not the same as "I configured and verified it."
• Are there audit logs? Every read and write of PHI should leave an immutable trail: who, what, when. If your app has beautiful CRUD and no access trail, that's the gap an auditor finds first.
• Are secrets actually secret? API keys, database credentials, and tokens hard-coded in the repo or shipped to the client are the most common — and most embarrassing — finding. AI tools love to inline secrets.
• What's in your dependency tree? Every package is attack surface and potential PHI exposure. Generated apps often pull in far more than they use.

If that list made you wince, good — that's the honest starting point. Our blog goes deeper on the basics in security habits every health-tech team needs, and the 6-month HIPAA & SOC 2 checklist maps the longer arc.

Infrastructure, hosting, and the BAA chain

Here's the line that trips up almost everyone: the major clouds are HIPAA-eligible, not HIPAA-compliant out of the box. AWS, Azure, and Google Cloud all offer HIPAA-eligible services, but eligibility is the starting line. You still have to architect it correctly, lock it down, and — this is the part people skip — sign a Business Associate Agreement (BAA) with the provider.

A BAA is a contract that makes a vendor legally responsible for protecting the PHI they handle on your behalf. The rule is simple and unforgiving: every service that creates, receives, stores, or transmits PHI for you needs a signed BAA. That includes your hosting provider, your database host, your email and SMS vendors, your error tracker, your analytics, and the AI APIs you're calling. The BAAs hiding in your stack — the vendors you didn't think of as "handling PHI" — are where the real exposure lives.

This is also where running it yourself gets expensive in time. Cloud provisioning, network configuration, firewalls, backups, and the BAA paperwork is a full-time job for someone who's done it before. If you'd rather not build that muscle in-house, it's exactly what managed, HIPAA-eligible app and EHR hosting exists to absorb — a flat fee instead of a DevOps hire. And if a breach does happen, having recovery and response already in place is the difference between a bad week and an existential one; we wrote about that the hard way in a startup's breach-recovery story.

The App Store reality

Even with compliance handled, there's a separate gate: the app stores. In March 2026, Apple began blocking updates from popular AI app builders like Replit and Vibecode under Guideline 2.5.2 — a rule that's existed since the App Store launched. It says apps must be self-contained and can't download, install, or execute code that changes their own functionality or another app's. Apps that hot-load their logic at runtime, which several vibe-coding platforms do, run straight into it.

Health apps then draw extra scrutiny on top of that. Reviewers look hard at how you handle data, whether you have a privacy policy that matches what the app actually does, and — a frequent rejection cause — whether users can delete their account and data from inside the app. A prototype that runs fine in a web preview can hit a wall the moment you try to ship it natively.

The counter-argument is "so I'll just stay a web app." Sometimes that's right. But many healthtech products need to be on a phone — for notifications, for camera-based intake, for the simple reason that patients live on their phones. If native is on your roadmap, the self-contained build requirement and the health-app review items are things to design for now, not discover during a launch week you've already announced.

What not to do (and what not to use)

Listing good practices is easy. The differentiated advice is what to avoid.

Don't treat AI-generated code as finished. Treat it as a confident first draft from a junior who's never seen an audit. It will hallucinate security functions that look right and do nothing, and it will leave out the boring parts that matter most.

Don't store PHI in tools that won't sign a BAA. This rules out a surprising number of popular defaults: many analytics products, several error trackers on their free tiers, and most general-purpose LLM APIs unless you're on a tier that offers a BAA. If a vendor won't sign, PHI cannot go there — full stop.

Don't put compliance last in the plan. Retrofitting encryption, audit logging, and a clean data boundary after you've built on top of a leaky foundation routinely costs more than designing them in would have. The teams that bolt compliance on at the end are the ones that end up re-architecting during their pilot.

Don't confuse "it passed the demo" with "it's tested." AI-generated tests, when they exist, tend to assert the happy path. PHI handling needs adversarial testing — bad input, unauthorized access attempts, and failure injection — plus, before launch, a real security review rather than an automated scan alone.

A 30-day production-readiness plan

If you have a vibe-coded health app and a month, here's a realistic shape. Each week has a measurable "done" and a branch for if you're behind.

Week 1 — Map and audit. Done looks like: a written inventory of every place PHI lives, a list of every vendor in the path, and the self-audit above completed with each item marked pass/fail. If you're behind: you're probably discovering PHI in unexpected places — that's the point of the week, not a failure. Finish the map before writing any code.

Week 2 — Lock the foundation. Done looks like: encryption verified at rest and in transit, secrets moved out of code into a proper secrets store, and the HIPAA-eligible hosting configured with the provider BAA signed. If you're behind: prioritize secrets and encryption over everything else — those are the findings that end deals.

Week 3 — Audit trails and access. Done looks like: immutable logging of every PHI access in place, least-privilege access controls enforced, and the remaining vendor BAAs signed or those vendors removed. If you're behind: it's usually the BAA chase. Start it on day one of the week — vendors are slow.

Week 4 — Harden and prep launch. Done looks like: adversarial tests for PHI paths, a manual security review (not just automated scanning), account-deletion and privacy-policy items handled for App Store review, and your incident-response plan written down. If you're behind: don't ship. A slipped launch beats a breach. Cut scope, not safeguards.

This is deliberately aggressive, and it assumes the prototype is small. Larger apps take longer. The value of the timeline isn't the dates — it's the ordering: foundation before features, BAAs early because they're slow, and launch prep last.

A founder who did it the hard way

A founder came to us with a mental-health intake app built almost entirely with AI tools. The demo was genuinely good — clean flows, real clinical logic, a working prototype in under two weeks.

What surprised them: the audit didn't find one big problem. It found thirty small ones. PHI was being written to an analytics tool with no BAA. The "encryption" the AI had added was a base64 encode, which is not encryption. There were no audit logs at all. And three of the npm packages in the tree hadn't been updated in years. None of it was visible in the demo, and none of it was malicious — it was just the boring middle that AI tools skip.

The lesson: the work wasn't a rewrite. We kept most of the product and replaced the parts that mattered — real encryption, an audit trail, a clean PHI boundary, signed BAAs, and a hosting setup that could pass review. The prototype saved them real time on the visible product. It just hadn't started the invisible product yet, and that's the part that determines whether a health app can launch. It's the same arc we took Backpack through — MVP to a scalable, compliant platform that families actually use.

What "production-ready" actually looks like

You're production-ready when you can answer four questions without flinching. Where does PHI live, and is it encrypted everywhere it lives? Who can access it, and can you prove who did? Has every vendor in the path signed a BAA? And if something goes wrong at 2am, is there a written plan and a way to recover?

If those answers are solid, you're not just launchable — you're investable and pilot-able, because the people doing diligence ask exactly these questions. Compliance done right stops being a tax and becomes a moat: it's the thing your faster, sloppier competitor didn't do.

The honest part: most teams can't get there alone on a tight timeline, and that's fine. Building it right the first time is cheaper than rebuilding under pressure during a pilot. If you want a second set of eyes, that's what our production-ready audit and build is for — and if you're earlier and want to build it compliant from the first commit, start with healthtech app development for startups. Either way, the goal is the same: an app patients can trust, that ships, and that survives the first hard question.