2.1 · Our Approach
Our Stack and Why
Every piece of this section exists because we made one architectural decision and want to be able to explain it cleanly. The decision: we are going all-in on Amazon Web Services for the regulated path of this platform. Every vendor that ever touches Protected Health Information is either AWS itself or a service we explicitly chose because it integrates cleanly with AWS under the same Business Associate Agreement.
The decision in one sentence
We picked AWS because we get one signed Business Associate Agreement that covers our entire regulated stack, the data never leaves AWS’s network as it moves between services, the cost scales reasonably, and the platform is built precisely for the kind of long-running, sensitive workloads we are designing for.
What sits inside the AWS BAA
Every service below is covered by our single AWS Business Associate Agreement. The third column is the reason that service exists in our stack rather than a generic description.
| Service | What it does | Why it touches Protected Health Information |
|---|---|---|
| App Runner | Runs the Next.js application as a managed container. | The HTTPS request carrying an uploaded document lands here first, and App Runner reaches the database over a private VPC link, so the hosting layer is part of the regulated path. App Runner is HIPAA-eligible under the same Business Associate Agreement as the rest of the stack. |
| RDS Aurora Postgres | Primary database for clinic profiles, user accounts, intake submissions, AI gap analyses, and audit log entries. | Almost every non-file record ends up here. Encryption at rest is on by default and row-level security keeps clinic data separated. |
| S3 | Object storage for uploaded files. | Intake forms, insurance cards, treatment plans, and session notes live in encrypted S3 buckets with per-clinic isolation policies. |
| Bedrock with Anthropic Claude | The AI engine that analyzes uploaded documents. | Document content is sent to Bedrock, which runs Claude inside AWS’s own network. The data never leaves AWS to reach the model. |
| Cognito | Authentication and user identity. | Holds the records that prove who is logged in, what clinic they belong to, and what they are allowed to access. Multi-factor authentication is configured here. |
| CloudWatch | Logs and monitoring. | A scrubbing layer runs before any log call so identifiers never reach CloudWatch even when something crashes. |
| SES | Transactional email (password resets, intake confirmations, staff notifications). | Configured to never include Protected Health Information in the body of an email. |
| CloudFront | Content delivery network for the application. | Serves static assets globally. Regulated calls always route through the application layer, not the edge cache. |
| Secrets Manager | Holds API keys, database credentials, and other sensitive secrets. | Encrypted, access-controlled, audited. The application reads secrets at runtime under a tightly scoped role. |
Why not Vercel, Neon, or other simpler stacks
The alternative we considered was a hybrid path: Vercel for hosting, Neon for the database, and AWS just for AI and file storage. That path is real and works, but it would mean signing separate Business Associate Agreements with Vercel, Neon, and AWS, managing three vendor relationships during audits, and paying multiple vendor markups.
| Hybrid (Vercel + Neon + AWS) | All-AWS (what we chose) |
|---|---|
| Three Business Associate Agreements to sign and renew. | One Business Associate Agreement, one set of vendor terms. |
| Data crosses the public internet between vendors on every request. | Data stays inside AWS’s private network end to end. |
| Two layers of developer-experience markup over the underlying compute. | Pay AWS once, directly, with no middleman. |
| Three permission systems to reconcile during audits. | One AWS IAM model controls every part of the regulated stack. |
| Friendlier developer experience for small Next.js apps. | Steeper learning curve, offset by AI coding assistance and the AWS CLI. |
The tradeoff we accepted
AWS has a steeper learning curve than Vercel. Vercel hides the underlying infrastructure on purpose to make Next.js deployment feel easy. AWS does not. We accepted the learning curve because the long-term simplicity (one bill, one Business Associate Agreement, one set of credentials, one network) is worth the upfront effort. We work through the AWS CLI with AI coding assistance, which makes the learning curve far less steep than it would have been a few years ago.
What stays outside AWS
Not everything is on AWS. The public-facing marketing site, the development tooling, and the internal team productivity stack (Linear, GitHub, Slack, etc.) live elsewhere. None of those touch Protected Health Information, so they do not need to be inside the Business Associate Agreement chain. The line is clean: regulated data lives in AWS, everything else lives wherever serves it best.
How to read this page later
Six months from now, you will likely look at the AWS bill and wonder why we did not pick a cheaper or simpler option. The answer is on this page, and it is worth reading before making a switch. The architecture is not optimized for being inexpensive in absolute terms. It is optimized for being legally defensible, technically clean, and capable of scaling to dozens or hundreds of clinics without revisiting these decisions.