The inbound says: "We are a small home-health agency, we love your product, can you sign a BAA?" A BAA is a Business Associate Agreement under HIPAA, the U.S. law that governs Protected Health Information (PHI). Sign one and you are legally accountable for PHI you touch. The wrong answer is "no, we are not HIPAA-compliant" (you lose the customer). The wrong answer is also "yes" before you have done the work (you have just signed up for unbounded liability).
This is the maker-sized version of the right answer.
Worth reading first as context: Courier's "How we became HIPAA-compliant" (originally on HN as HN 32321473, 2022-08) is the most honest small-team writeup of the process. And the r/SaaS thread "Solo founder, built a compliance SaaS for home health agencies" (4 points, 21 comments) is a recent ground-truth of what home-health buyers actually ask for.
Piece 1: hosting under a signed BAA
If you are on AWS, GCP, Azure, or DigitalOcean, the BAA is a click-through under "compliance" or a separate signed addendum. AWS: HIPAA-eligible services list, sign BAA in AWS Artifact. GCP: Cloud HIPAA agreement via the Compliance Reports Manager. DO: does not sign BAAs as of writing — if you are on DO, you have a hosting migration ahead of you before you can credibly say yes.
Concrete deliverable: a PDF of the signed BAA with your hosting provider, in your records.
Piece 2: encryption posture, both transit and rest
TLS in transit is table stakes (it is already on for every modern stack). At-rest encryption is where solo makers cut corners and get caught. Every database, every file store, every backup, every log sink that touches PHI must be encrypted. Most managed databases (RDS, Cloud SQL) have this as a checkbox at creation; turning it on later is harder than turning it on now.
For your no-code platform, check the vendor docs. Some encrypt by default; some require an enterprise plan; some do not encrypt at all. If your no-code platform does not encrypt at rest, you cannot ship PHI through it, full stop.
Piece 3: access logs, with retention
HIPAA's audit-control requirement is concrete: you must log who accessed which PHI record, when, and from where. The retention requirement is six years. Most no-code platforms log admin actions but not record-level reads. If your product surfaces PHI, you either need a no-code platform with record-level audit logging or a layer in front of the platform that does the logging.
Practical solution for makers: route PHI reads through a small middleware (a Cloud Function or a Lambda) that logs the access event to a write-once log store, then proxies the read. This is the pattern Courier used and it scales fine for the volume a small SaaS sees.
Piece 4: a signed BAA from every vendor in the data path
This is the piece that catches everyone. Your hosting provider, your email transactional vendor, your AI vendor, your error-monitoring service, your analytics tool, your CDN — every single piece of infrastructure that could see PHI needs a signed BAA. If any one of them does not offer BAAs, that piece has to come out of the PHI path.
Common pain points: Sentry offers a BAA on enterprise plans only. OpenAI offers a BAA via Zero Data Retention agreement, but not on the default API. Anthropic's BAA arrangement is similar but evolving. Posthog, Mixpanel, segment.com — most analytics vendors do not offer BAAs at all, which means no PHI in events, which means a careful event-design exercise.
This is usually the two-to-six-week part of the process. Start it the day a prospect mentions PHI, even if you have not signed yet.
Piece 5: a written breach response plan
HIPAA requires a documented plan for what happens if PHI is exposed. The plan does not have to be long; it has to exist, be specific to your stack, and be findable when needed. The minimum: who gets notified internally, how customers are notified, how regulators are notified, what the timeline is, who holds the customer notification template, where the incident log lives.
Two pages. A Markdown file in your ops repo. Reviewed by you once a year. That is enough at solo-maker scale and is the baseline auditors look for.
Piece 6: signing the BAA back to the customer
Most home-health and clinical buyers will send you their template. Read it. The dangerous clauses are usually: (a) indemnification with no liability cap (push back hard, offer a cap of 12 months of fees or similar), (b) right-to-audit on demand (negotiate to "once per year with 30 days notice"), and (c) data-deletion timelines shorter than your backup retention (align them or change your backup retention).
If you do not have a lawyer who has reviewed a HIPAA BAA before, hire one for one hour. The redlines are mechanical for someone who has seen the form three times.
What you do not need
You do not need a SOC 2 report to sign a BAA. SOC 2 is a separate audit on a different framework that some larger healthcare buyers will additionally request, but BAA-signing requires the six pieces above, not a SOC 2.
You do not need to be HIPAA-certified. There is no federal certification body. Anyone who says "HIPAA-certified" is using marketing language; the legal status is "HIPAA-compliant with a signed BAA." That is what matters.
What I would actually do
- Day 1: hosting BAA. Sign it on whatever provider you are on. If your provider does not offer one, plan the migration.
- Day 2-3: encryption posture. Verify every store is encrypted at rest. Flip the switches that need flipping.
- Day 4-14: vendor BAAs. List every vendor in the data path. Email each one. Track the responses. Remove from the PHI path anyone who will not sign.
- Day 15: access logging. Add the middleware or turn on the platform's audit feature.
- Day 16: breach plan. Two-page Markdown file. Done.
- Day 17: customer BAA. Lawyer-reviewed redlines, sign.
The honest framing: HIPAA at solo scale is mechanical. It is not a year-long effort. The vendor-BAA step takes calendar time you cannot compress; everything else is a day of work. The customers who ask for a BAA are also the customers who pay 3-5x the rate of consumer SaaS, so the work pays back fast.