The Developer Bottleneck
For years, the bottleneck for a healthcare professional with an idea for a patient tool was development cost. A secure web application cost tens of thousands of dollars to build.
Claude Code collapsed the build cost. It did not collapse the compliance cost, and I want to say that up front. Writing the code got close to free. A Supabase HIPAA add-on with paid compute, a paid Google Workspace tenant with an executed BAA, a security engineer to review my database policies and key handling, a lawyer to write the privacy policy, and a regulatory read on whether my app is a medical device did not. That is the real budget now, and it is a fraction of what it was, but it is not zero and you cannot prompt your way past it.
One more thing to settle first: is this a medical device? FDA lists software that lets a user log and trend their own health measurements as a device function it currently exercises enforcement discretion over. Enforcement discretion is not the same as "not a device". It is a policy position FDA can narrow, and it evaporates the moment your app adds an alert, a clinical threshold or a recommendation. My app displays what the user typed and nothing else. If you cannot say the same about your build, get regulatory advice before you ship.
I built the Hunters Holistic Health (HHH) platform with Claude Code. I am a PharmD, not a software engineer.
The Architecture of HHH
HHH is a React-based Progressive Web App (PWA) with a Supabase backend, a patient dashboard, a daily log, an AI Meal Guard, and an n8n intake routing system.
Before the architecture, the threshold question: which law actually applies to you? HIPAA binds covered entities and business associates. HHS is explicit that an entity meeting neither definition does not have to comply with the HIPAA Rules. If you are a licensed provider building a tool that touches your own patients' information, you are a covered entity and HIPAA applies. If you are building a direct to consumer wellness app with no provider relationship, HIPAA very likely does not apply to it, and many people stop there and assume they are unregulated. They are not. The FTC Health Breach Notification Rule covers health apps that HIPAA does not, and it obligates you to notify affected consumers and the FTC after a breach of unsecured health information, plus the media at 500 people or more.
I am a pharmacist, so I sit on the covered entity side, and I built a strict two-layer architecture to keep the two worlds apart:
- Lane 1 (The App): Handles general wellness tracking and operational intake for self enrolled users. Be honest about what this lane holds. A daily health log attached to a named user account is individually identifiable health information under 45 CFR 160.103, which defines health information as anything relating to an individual's physical or mental health, identifiable when it identifies the person or can reasonably be used to identify them. No diagnosis and no lab value is required. So Lane 1 is not a "no health data" lane. It is a lane that holds identified health data and therefore has to be secured and, if I am acting as a covered entity, covered by a BAA with every vendor that touches it. FDA's General Wellness guidance also draws a hard line: a product stops being a general wellness product if its interface includes references to specific diseases, clinical conditions or diagnostic thresholds, alerts that recommend clinical action, or treatment guidance. That constraint shaped every screen. The app never labels an entry good or bad, never names a condition, and never suggests a change to anyone's care.
- Lane 2 (Google Workspace): A separate, manual lane for actual clinical records and PHI, running on a paid Google Workspace tenant where I reviewed and accepted Google's BAA in the Admin console under Account settings, Legal and compliance. A personal Gmail account cannot do this.
Every vendor that stores, transmits or can access PHI on your behalf is a business associate and needs a signed BAA. HHS says encryption does not get you out of it, in these words: lacking an encryption key does not exempt a cloud service provider from business associate status. That means Supabase too. Supabase requires a signed BAA plus the HIPAA add-on enabled, along with Point in Time Recovery, SSL Enforcement and Network Restrictions. That is a paid configuration, not the free tier. And if you wire an AI model into your app, that vendor is in the data path as well. Count your vendors, then count your BAAs. The numbers have to match.
The Claude Code Process
Here is exactly how I built it using Claude Code:
1. The Master Prompt (CLAUDE.md)
Before writing any code, I wrote a comprehensive `CLAUDE.md` file. I explicitly defined the two-layer architecture and added a "HIPAA Hard Stop" rule: *If any feature may create, transmit, or store individually identifiable health information, STOP and ask for confirmation.* The rule told the AI to stop and ask before building any table that would hold health information.
2. The Data Layer First
I instructed Claude Code to build the Supabase SQL schema first. We defined tables for daily logs and waitlist signups, storing the minimum necessary and keeping the clinical record out of the app entirely. I want to correct a rule people repeat to themselves here, because I repeated it too: "no diagnoses and no lab values means no PHI" is not the test. HIPAA's Safe Harbor standard treats data as de-identified only when all 18 listed identifiers are stripped, and that list includes names, email addresses, any date more precise than the year, and IP addresses. The moment your app has user accounts, the data in it is identified.
Then the step that does the most damage when it is skipped. Supabase exposes your public schema over an API, and your anon key ships inside the browser bundle where anyone can read it. Supabase's own docs put it this way: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, so enable RLS on every table in an exposed schema. Row Level Security is not on by default when you create tables with raw SQL, which is exactly what we just did. So I made Claude Code do five things before a single UI screen existed:
1. Enable RLS on every table, then write a policy so a user can read and write only rows where the row's user id equals auth.uid(). Their docs also warn that adding policies alone does not remove existing grants, so revoke first and grant back only what you need.
2. Write tests that log in as user A and try to read user B's rows, and confirm they fail. Do not take the model's word that the policy works. Run the test.
3. Keep the service role key server side only, in environment variables, never in the client, never in the repo. Add .env to .gitignore before your first commit, because a key pushed to GitHub is a key that is already compromised.
4. Turn on Point in Time Recovery and confirm you can actually restore, by restoring. A backup you have never tested is a hope, not a backup.
5. Require real authentication with email verification, and turn off public signups for anything you do not want strangers in.
I am not an engineer, so I could not verify any of this by reading the code. That is why I paid a security engineer to review the schema, the policies and the key handling before a single real person's data went in. Budget for that review. It is one of the cheapest line items in the project.
3. The Vibe Coding Loop
I built the app one page at a time. I would type: *"Build the daily log page. Use Chart.js for the trend line. Remember the design tokens in tokens.css."* Claude Code would write the file, update the routing, and clear the TypeScript errors. Be clear about what that last part proves: a clean compile means the types agree with each other. It says nothing about whether the row level security policy actually blocks user B from reading user A's entries, whether a key ended up in the browser bundle, or whether the chart plots the number the user actually entered. AI generated code is a fast, competent first draft, not a shipped product. Every screen that touched user data got three things before it went live: a test I could run and watch fail, a read through by a paid engineer, and a manual check against data I entered by hand and knew the correct output for.
4. The n8n Integration
Instead of writing complex backend routing, I had Claude Code build a webhook connection to n8n. Now, when someone fills out an intake form on the app, Claude's code sends it to my self-hosted n8n instance, which routes it to the correct Google Sheet. Self-hosting n8n means n8n itself is not a vendor holding my data, and that is a genuine reduction in surface area. It is not a compliance loophole. Google Sheets is still a third party cloud service, and if intake data ever contains PHI, Google is a business associate that needs a BAA no matter how many self-hosted hops the data took to get there.
The Lesson for Healthcare Professionals
You do not need to learn React. You do need to learn system architecture, compliance constraints, and enough about testing to know what "it works" means. If you can define what needs to be built and what the rules are, Claude Code can draft the how. It cannot tell you whether the result is safe, and neither can you if you never learn to check. Hire the review. That is not a failure of the method, it is part of the method.
Building HHH showed me that code is no longer the bottleneck for domain experts. Judgment still is. I built the thing. I did not certify it, and this post is a description of my process. It is not legal advice and not a compliance opinion for yours. Get your own regulatory and security review before a single real person's health data goes into anything you build.