The first time I built a regulated product as a solo dev, I spent two weeks evaluating compliance tooling before writing a line of application code. That was two weeks too long. Most of what I built later required a third of the categories I had evaluated, and the ones that mattered had simple rules I could have applied in an afternoon.
These are the field notes from that mistake and the rebuild that followed. The rules for picking tools. The stack I actually run. The categories I now deliberately skip. The tooling decisions sit inside the regulated DTC healthcare architecture overview, and the pattern has been applied across prior regulated-build engagements in the work archive.
- Auth + sessionbuildBAA: inside
- Audit logbuildBAA: inside
- Analytics eventsbuildBAA: inside
- Transactional emailbuyBAA: vendor
- Voice / SMSbuyBAA: vendor
- File storagebuyBAA: vendor
- Error monitoringbuyBAA: vendor
- Compliance automationskipBAA: n/a
The rules I pick tools by
Three rules, in order of precedence. If rule 1 fails, nothing else matters.
Rule 1: BAA availability is the first filter. If the vendor does not offer a business associate agreement, the conversation ends. Not "offers one on the enterprise plan for an extra $2k a month." Offers one on a plan I can afford. This alone rules out maybe 70 percent of indie-friendly SaaS. That is fine; 70 percent of indie-friendly SaaS is not built for regulated products.
Rule 2: Data portability, tested. Can I export everything I care about in a format that imports into the next vendor? I run this test at signup, not at renewal. A vendor that makes export hard at month one will make it harder at month eighteen. CSV, JSON, or a documented API that covers the whole data model. I have been burned twice by vendors whose export covered 80 percent of the data and silently lost the last 20.
Rule 3: Small enough to read the contract. On a solo build, I do not have a lawyer on retainer. I need to be able to read the BAA and the main terms myself. Vendors with simple plain-language contracts age better than enterprise vendors whose terms reference 14 exhibits. If I cannot understand the sub-processor chain after 30 minutes of reading, the vendor is probably not built for my scale.
The stack, by category
The categories I stack for a regulated product. Tools named where the vendor has a public BAA policy as of writing; check the current BAA offering before signing anything.
Hosting + functions. Vercel Enterprise tier offers a BAA. AWS offers BAAs for most services (HIPAA-eligible services list). For solo builds, Vercel for the Next.js layer and AWS for the heavier workloads is the combo I have used most. The sub-processor question from the BAA and vendor-risk walkthrough matters here, because Vercel runs on AWS, and you want the BAA chain to be intact.
Database. Supabase offers a BAA on enterprise plans. Neon offers one on Business. Managed RDS under your own AWS BAA. For solo builds, Supabase is the most productive for the first six months and migrates cleanly to self-managed Postgres if scale or the BAA terms push you there.
Email (transactional and marketing). Resend offers a BAA on custom enterprise terms. SendGrid has one on Pro and Premier. For member-facing email that could contain PHI, default to no PHI in the body, use the platform for delivery only, and put the sensitive content behind a login link. Most regulated products I have built never need a BAA for email because no PHI ever enters the email body.
Voice and SMS. Twilio offers a BAA under Commercial Agreement. Bandwidth offers one. For solo builds, Twilio is the default because the developer experience is strongest and the BAA is not gated behind a sales cycle for small volumes.
File storage. S3 under your own AWS BAA. Cloudflare R2 under a BAA via sales. Supabase Storage under the same BAA as Supabase. For any product that stores attachments (uploads from members, generated PDFs, documents), pick the one that matches your hosting stack to keep the BAA chain short.
Error monitoring. Sentry offers a BAA on enterprise. This is the category where I have done the most migration. The default Sentry configuration captures request bodies, which in a regulated app is a liability. Turn off auto-capture of request bodies. Scrub PII in the ingest layer. Treat error monitoring as "events about errors" not "event logs."
Analytics. Covered in detail in the regulated analytics without GA4 piece. The short version: warehouse your own events, buy a BAA-tier replay vendor only if the support team needs it, split the marketing domain from the app domain.
Secrets. Vercel environment variables for the Next.js layer. AWS Secrets Manager for anything AWS-side. No third-party secrets manager. The boundary is "does the secret ever land in a log or a third-party system," and a managed provider's own infrastructure keeps that boundary tight.
Scheduled jobs. Next.js cron via Vercel or a simple Postgres pg_cron extension. Avoid third-party scheduling platforms for anything that touches PHI, because the job payload often becomes the easiest place for data to leak.
The categories I deliberately skip for solo builds
The categories that look necessary and are not.
Compliance automation platforms. Vanta, Drata, Secureframe, Thoropass. These are excellent products for organizations that need to show SOC 2 or HIPAA posture to enterprise buyers. They are overhead for a solo build in year one. The work they automate is the right work; the price is not. For a solo build, a Notion page that tracks the same controls, updated quarterly, gets you the same operational discipline without the subscription. When the business starts selling to buyers who demand Vanta, revisit.
Unified observability. Datadog, New Relic, Grafana Cloud with the full stack. For a solo product, a single error monitoring tool plus Postgres queries against your own logs gets you 90 percent of the diagnostic value. The remaining 10 percent is worth revisiting at year two, not year one.
Enterprise identity providers. Okta, Auth0 on enterprise tiers. WorkOS for SSO. These are useful when a B2B customer demands SAML. They are not required for a direct-to-member product. Roll your own auth with the pattern from session and token rotation for healthcare apps, or use Auth.js with a self-managed Postgres adapter.
Third-party admin dashboards. Retool and similar. I love these tools and have shipped them in non-regulated products. For a regulated product, they add a vendor to the PHI chain for work that can happen in a few internal Next.js admin pages. The Next.js admin pages are 2-3 days of work and keep the PHI chain short.
The build-vs-buy line
The line I end up at, for a solo regulated build:
| Category | Decision | Reason | |---|---|---| | Auth | Build | Rotation pattern needs tight control | | Audit log | Build | Role-based append-only is a 1-day task | | Analytics events | Build | Warehouse is application code | | Transactional email | Buy | Resend or SendGrid, BAA-tier | | Voice / SMS | Buy | Twilio, no contest | | File storage | Buy | S3 under your own BAA | | Error monitoring | Buy, configure heavily | Sentry with PHI scrubbing | | Scheduled jobs | Build | Vercel cron or pg_cron | | Secrets | Buy, same vendor as hosting | Minimize surface | | Compliance automation | Skip | Notion tracking suffices |
The pattern is: buy the hard infrastructure (email delivery, telephony, object storage), build the boundary-sensitive layers (auth, audit, analytics, admin). The opposite is how most solo builds end up, and it is why so many of them end up with PHI in a third-party tool the founder forgot they integrated.
The one rule I break
I claimed three rules earlier. I break the portability rule for Sentry. The export from Sentry is functional but rough, and I have not found an error-monitoring alternative that matches the ergonomics at the same price point. The compromise is that I do not store anything in Sentry that matters six months later. Errors in there are diagnostic, not records of truth. If the vendor relationship ends, I lose diagnostic history, not business data.
Every solo build ends up with a compromise like this. The rule is that the compromise lives in one category, not five. If I ever find myself breaking the BAA rule, the portability rule, and the contract-length rule all in different categories, the stack has drifted and it is time for a review.
“Buy the hard infrastructure. Build the boundary-sensitive layers.”
FAQ
Do I actually need a BAA for everything on day one?
You need a BAA for any vendor that will touch PHI before PHI flows. Day one is often build-time when no real PHI exists. The BAA needs to be in place before the first real member record hits the system. Plan the signing timeline around that milestone, not around signup.
What about Supabase or Neon on the free tier?
Neither currently offers a BAA at the free or starter tiers. Use them for the prototype, migrate to a paid tier with BAA before any real PHI arrives. The migration from starter to paid is usually a single CLI command; the migration from "PHI is already in the starter database" is a compliance incident.
Is Cloudflare R2 a good fit for a regulated solo build?
Cloudflare offers a BAA through their sales team. R2 is excellent for file storage economically. The friction is that the BAA conversation requires sales contact; if you prefer self-serve, S3 under your own AWS BAA is less friction for a solo build. Both are fine choices once the BAA is in hand.
Why not Vanta if I want to sell to enterprise later?
Nothing wrong with Vanta when the enterprise sales cycle starts. Adopting it on year one adds a $5 to 15k annual line item for tooling that the business does not yet need. The controls Vanta tracks are the ones you should be doing anyway; do them in a spreadsheet until a customer demands proof. Migration from spreadsheet to Vanta is straightforward.
What is the biggest mistake you see with solo regulated builds?
Integrating a third-party service that handles user data without a BAA, then finding it at year two during a security review. Stripe used to be the most common; Stripe now offers a BAA for healthcare accounts. The current most-common culprits are analytics vendors, session replay tools, and support chat widgets.
How do I evaluate a new vendor category quickly?
The vendor-evaluation checklist in the BAA and vendor-risk walkthrough covers the 10 questions I ask. Shortest version: does the vendor sign a BAA at a price I can afford, can I export my data in a format the next vendor can import, can I read the contract without a lawyer. If all three are yes, move to a technical trial. If any are no, keep looking.
Sources and specifics
- HIPAA BAA requirement: 45 CFR 164.504(e). Business associates must have a signed BAA before PHI is disclosed to them.
- AWS HIPAA-eligible services list is maintained at the AWS HIPAA compliance page; covers the majority of the AWS catalog.
- Vendor BAA availability as of Q2 2026; specifics change and should be verified on the vendor's current pricing page before signing.
- Build-vs-buy decisions draw from production regulated member platforms without naming specific clients or systems.
- Analytics category is covered separately in the regulated analytics without GA4 piece.
- Error monitoring PHI scrubbing references Sentry's
beforeSendhook and data scrubbing documentation; the same pattern exists in most error-monitoring SDKs.