Building web apps for healthtech without the pain

Most healthtech projects do not fail because the engineering is hard. They fail because the founder learns about HIPAA, audit logs, and signed business associate agreements three weeks before a pilot, when the architecture is already locked in. The good news: if you plan for the boring parts up front, building a healthtech web app is not that different from building any other serious product. The pain comes from retrofitting compliance, not from compliance itself.

What actually makes healthtech different

A healthtech app is a normal web app with a few extra rules that touch almost every layer. If you handle protected health information (PHI), three things change.

First, every system that touches PHI needs a business associate agreement (BAA). That includes your database host, your email provider, your error tracker, your analytics, and your file storage. If a vendor will not sign a BAA, you cannot send PHI through it. Plenty of popular tools (some analytics platforms, some logging services) simply will not, and you find out the hard way.

Second, you need an audit trail. Who viewed which patient record, when, and from where. This is not a nice-to-have you bolt on later. It needs to be designed into your data access layer so it cannot be bypassed.

Third, access control gets specific. "Logged-in user" is not enough. A nurse, a billing clerk, and a patient should see different slices of the same record. Role-based access has to be real, tested, and enforced server-side, the kind of thing a web application security checklist helps you stay honest about.

None of this is exotic. It is just non-negotiable, and it shapes decisions you would otherwise make casually, much like the constraints we cover for fintech web apps.

PHI is the line that matters

The single most useful thing you can do early is draw a clear boundary around PHI. A scheduling feature that stores names and appointment times is regulated. A marketing landing page is not. Keep them in separate systems where you can. The less of your stack that touches PHI, the smaller your compliance surface, and the cheaper and faster everything gets.

A stack that does not fight you

For most healthtech web apps we build, the shape looks like this: a Next.js or React front end, a Node and TypeScript API and backend, and Postgres for data. Nothing surprising. The choices that matter for healthtech are about where things run and who signs paperwork.

Hosting: pick infrastructure that will sign a BAA. AWS, Google Cloud, and Azure all will, under their eligible services. Managed Postgres providers vary, so confirm before you commit. Encrypt data at rest and in transit. This is mostly a configuration checkbox now, not a project.

Auth: use a provider that handles this seriously rather than rolling your own. Several identity providers support HIPAA-eligible configurations. The win is that password storage, MFA, and session handling are someone else's full-time job, not yours.

Logging and monitoring: this is where teams trip. Your normal instinct is to log request payloads for debugging. In healthtech, a payload might contain a diagnosis. Scrub PHI out of logs and error reports by default, and treat any logging vendor as a system that needs a BAA.

A small, practical pattern that saves real grief: route every data read through a layer that records access, instead of querying tables directly from your route handlers.

// Every read of patient data goes through this, so the audit log
// can never be silently skipped by a new endpoint.
async function getPatientRecord(actor: User, patientId: string) {
  assertCanView(actor, patientId); // role check, server-side
  const record = await db.patients.findById(patientId);
  await auditLog.write({
    actorId: actor.id,
    action: "view_patient",
    patientId,
    at: new Date(),
  });
  return record;
}

It is not clever code. The point is that the audit and access check live in one place that every feature must go through, so a junior dev adding a new screen next year cannot accidentally leak data or skip the log.

Timelines and rough costs

These are ranges, not quotes. Every project differs, and anyone who gives you a fixed price before understanding your data is guessing.

A focused pilot (one core workflow, real PHI, proper auth and audit logging, a clean compliance boundary) is usually a 10 to 16 week build with a small senior team. The compliance scaffolding adds maybe 15 to 25 percent on top of what the same app would cost without PHI. Most of that is in design care and testing, not exotic tooling.

A larger platform with multiple user roles, integrations with an external system, and patient-facing plus staff-facing views is more often a 4 to 8 month effort, then ongoing. The integrations are usually the slow part, not your own code.

On budget, think in bands rather than a single number. A serious pilot built by senior people generally lands in the low-to-mid five figures monthly while in active development, depending on scope and how much the team is doing versus advising. The expensive mistakes are not engineering hours. They are rebuilds caused by skipping the boundary work at the start.

Where the schedule slips

Two things blow up timelines more than anything else. One is vendor paperwork: getting a BAA signed can take days or weeks depending on the company, so start those conversations on day one. The other is integrations. If you need to talk to an external records system or a lab, the spec is often messy, the test environment is flaky, and their team moves on their own clock. Budget slack for it.

What to watch out for

A few traps come up again and again.

Do not store PHI in places you forgot were systems: spreadsheet exports, support tickets, screenshots in a shared drive, a Slack channel where someone pasted a record to debug. Compliance is about the whole flow, not just the database.

Do not treat "HIPAA compliant hosting" as the finish line. Hosting on eligible infrastructure is necessary but not sufficient. Your app can still leak PHI through a logged URL or an over-broad API response. The hosting badge covers the floor, not your code.

Be careful with off-the-shelf analytics and session-replay tools. Session replay in particular can record a clinician typing notes. Either disable it on PHI screens or use a tool that masks input and will sign a BAA.

Get your access rules written down before you build them. "The doctor can see everything" sounds simple until you ask whether a doctor can see a patient who is not theirs. Decide the rules with whoever owns the clinical workflow, then encode them once.

Finally, do not over-engineer. You do not need a microservices fleet or a custom compliance platform to run a pilot. A well-structured monolith on eligible infrastructure, with a clean PHI boundary and honest audit logging, covers most early-stage healthtech apps. Add complexity when you have users and data telling you to, not before.

The takeaway

Healthtech building is mostly normal web development with a clear boundary drawn around the regulated data, signed paperwork with every vendor that touches it, and an audit trail you cannot bypass. Decide those three things in week one and the rest of the project feels like any other build. Try to add them at the end and you pay for it twice.

If you want a second set of eyes on your architecture before you commit, we are happy to look. That is the good kind of lazy: doing the boring work early so you do not redo it later.