Senior Engineering for Telehealth SaaS — Ship Without Breaking HIPAA
Multi-tenant data isolation, visit-and-subscription billing, and per-state routing — engineered to fit inside your HIPAA program, not replace it.
The problem
Telehealth SaaS is one of the few categories where every engineering shortcut shows up later as either a regulator letter or a refund cycle. A tenant-isolation bug isn't a curiosity, it's a 500-individual breach notification to OCR. A wrong-state visit isn't a routing edge case, it's an unlicensed practice complaint. A billing double-count on a $200 visit isn't a friendly chargeback, it's a clinician threatening to leave the platform.
Single-DB prototype can't separate clinics
Founders in this space typically arrive at the same wall around month nine. The no-code prototype that got the first 100 patients can't safely separate two clinics on the same database. PHI scoping is enforced — if at all — in application code that one forgotten WHERE clause turns into a breach incident.
Billing layer can't carry visits plus subscriptions
The Stripe integration that bills subscriptions can't also bill per-visit fees, can't handle a credit pool a payer prepaid, and can't reconcile when a webhook arrives out of order. The same patient is billable across at least three pricing dimensions on the same day, and the integration has no model for that.
Cross-state licensure logic
The clinician scheduling logic that worked for one state breaks the day a patient travels and books from a state the clinician isn't licensed in. The visit legally takes place in the patient's state at the time of the appointment, not the clinician's home state — and 50-state license catalogs plus compact memberships do not survive being encoded as if-statements.
OCR enforcement tightening
OCR enforcement is also tightening — risk-analysis failures showed up in 76% of 2025 enforcement actions, and the average month sees roughly 47 large breaches reported. The cost of getting tenant isolation, audit logging, or encryption-at-rest wrong is no longer a hypothetical regulator letter.
Bus factor of one
Senior engineering capacity at this stage is hard to recruit. The clinicians on the cap table need product features; the investors want unit economics; and the founder is the only person who can hold the architectural picture in their head — which means the bus factor is one.
What changes for your business
What senior engineering buys a telehealth SaaS is fewer surprises and shorter feature cycles, inside the compliance regime you've already committed to. Most of the work is the same primitives a serious B2B SaaS needs, with two telehealth-specific twists on top.
Multi-tenant Postgres, hybrid billing, cross-app SSO
The primitives: multi-tenant Postgres with row-level security so two clinics on the same instance cannot read each other's PHI even through a SQL injection; a billing layer that handles a Stripe subscription, per-visit charges, and a prepaid credit ledger as one consistent system reconciled against Stripe webhooks; a session and SSO design that lets the patient app, clinician app, and admin console share identity without duplicating credentials; observability that surfaces a problem before a clinician opens a support ticket. We've built exactly this architecture across seven production apps inside BFEAI — multi-tenant Supabase with RLS, Stripe subscription plus dual-pool credit billing with webhook reconciliation, custom JWT cross-app SSO with refresh-token rotation. The patterns transfer cleanly.
Licensure routing as a catalog, not if-statements
The first telehealth-specific twist is licensure routing. A telehealth appointment legally happens in the state where the patient is physically located at the time of the visit. That means your scheduling logic has to know which clinicians hold which licenses in which states, route accordingly, and refuse to book a visit it shouldn't. The Interstate Medical Licensure Compact covers 43 states plus D.C. and Guam, but most platforms also need to handle the Nurse Licensure Compact, the APRN Compact, PSYPACT for psychologists, and individual state registrations on top. A senior engineer designs that as a license catalog and an eligibility check, not as 50 if-statements scattered through the booking flow.
Visit-state machine drives the billing event
The second twist is the visit-state machine. Async messaging, sync video, audio-only visits, asynchronous photo review, and store-and-forward consults each have different billing codes (Medicare's telehealth list now includes over 250 reimbursable codes, with POS 02 vs. POS 10 and modifiers 93 or FQ depending on the visit type and originating site), different documentation requirements, and different reimbursement timing. A clean state machine that says "this visit is in this state, only these transitions are allowed, and the billing event fires on this transition" prevents the entire class of bugs where a visit gets billed twice, gets billed at the wrong rate, or falls through without being billed at all.
The outcome is simple. Founders stop losing engineering weeks to plumbing, the clinical team stops shipping product workarounds for engineering gaps, and the CFO stops doing manual month-end reconciliation in a spreadsheet.
What ships in a typical engagement
Engagements are bounded and concrete. The most common shapes:
- Architecture audit, two to four weeks. A written engineering memo: where the data model leaks tenant boundaries, where the billing logic will fail at scale, where the licensure routing has gaps, what we'd ship first, and what we wouldn't touch. The memo is yours whether or not you continue.
- Billing rework. Move a single-product Stripe integration to a system that handles subscriptions, per-visit charges, prepaid credits, payer-funded credit pools, and out-of-order webhooks without losing money or double-charging. Includes a reconciliation report against Stripe so finance can stop spreadsheet-matching.
- Multi-state routing engine. A license catalog, an eligibility-check service, and a scheduling layer that refuses to book a visit a clinician isn't licensed for. Includes admin tooling so a compliance lead can update licenses without a deploy.
- Migration off a no-code prototype. Lift a Bubble, Retool, or Airtable-backed MVP onto a BAA-eligible Postgres, object store, and queue. Keep the product feature-set, replace the runtime, ship before the renewal cliff.
- EHR or e-prescribe integration. Modern REST/FHIR vendors (Canvas, Healthie, Elation, athenaOne, DoseSpot) wired in as a bounded service with retries, idempotency, and audit logs.
- We won't own HIPAA or SOC 2 certification. Your Privacy Officer and your auditor own those. We engineer inside the controls you've already committed to. If you don't yet have a Privacy Officer or a Security Rule risk analysis on file, we'll ask you to bring a healthcare-fluent compliance partner before we start.
- We won't write the clinical content or the medical decision logic. Symptom triage, clinical protocols, formulary rules, and risk stratification belong to your clinical team. We'll wire what they specify, with audit logging on every decision branch.
- We won't build a private interface to a legacy on-prem EHR. That's a specialist integrations vendor. We'll tell you up front whether your target system is reachable through standard APIs or whether you need a different kind of help.
- We won't take a single-engineer dependency you can't recover from. Code is documented, infrastructure is described in version control, and an internal engineer can take the work over without a knowledge-transfer crisis. The goal is to leave your team stronger than we found it, not to make ourselves load-bearing.
Every engagement ships a short engineering memo at the end: what we built, what's left, where the next failure modes are likely to surface. The handoff is the deliverable as much as the code.
What we won't take on
A few hard lines, stated up front so the engagement doesn't surprise anyone:
Outcomes you should expect
What this delivers
- Stop losing engineering weeks to plumbing — RLS, JWT sessions, audit logs, and webhook reconciliation that already work in production elsewhere
- Bill correctly for visit fees, subscriptions, and credit pools without manual spreadsheet reconciliation at month-end
- Route patients to clinicians by state, license, and modality with logic your support team can actually read
- Cut time-to-first-prescription, first-visit, or first-claim down from quarters to weeks per new feature
- Ship inside your existing HIPAA and SOC 2 program — without dragging a contractor into your compliance scope
Industry data
By the numbers
OCR received an average of 47 large healthcare data breaches per month between September 2025 and January 2026, and roughly 62 million individuals were affected by reportable breaches in 2025.
A telehealth visit legally takes place in the state where the patient is physically located at the time of the appointment, so providers must hold a license or registration valid in that state — not just in the clinician's home state.
The Interstate Medical Licensure Compact now covers 43 states, Washington D.C., and Guam, with additional compacts (NLC, APRN, PSYPACT) layered on top for nurses, advanced-practice nurses, and psychologists.
Medicare's telehealth services list includes more than 250 reimbursable codes, with Place-of-Service 02 vs. 10 and modifiers 93 or FQ required depending on visit type and originating site.
HIPAA's Security Rule requires encryption of ePHI in transit (TLS 1.2 or higher in practice) and at rest, with risk-analysis failures cited in 76% of OCR enforcement actions in 2025.
Live in production today
The same engineering, shipped in production at BFEAI.
I'm co-founder & CTO of Be Found Everywhere (BFEAI), a 7-app AI SaaS platform running today. The work I deliver for clients is the work I do every week on my own platform.
7
Production apps
200K+
Keywords generated
1,500+
AI scans run
7,000+
Sites automated
Common questions
What buyers ask before reaching out
Does BoostFrame take on HIPAA or SOC 2 compliance as the contractor?
No. We work inside your existing compliance program — your Privacy Officer, your BAAs, your auditor own the certification. We write code that fits the controls you've already defined: least-privilege access, encryption at rest and in transit, audit logging, separation of PHI and PII, BAA-covered infrastructure choices. If you don't yet have a Privacy Officer or a Security Rule risk analysis on file, we'll point you to a compliance partner first.
I'm pre-launch and don't have a BAA-covered stack yet. Can you help?
Yes — we can scope the engineering side of moving onto a BAA-eligible Postgres, object store, queue, and email provider before you accept the first patient. That work is bounded and concrete. We'll still ask you to bring a healthcare-fluent compliance advisor in parallel so the policy and risk-analysis paperwork lands at the same time the code does.
Why senior engineering instead of a typical agency or offshore team?
Telehealth combines three pieces — multi-tenant data isolation, mixed billing models, and per-state licensure logic — that each have failure modes a junior team will not catch until production. A senior engineer who has shipped multi-tenant Supabase with row-level security, Stripe subscription plus dual-pool credit billing with webhook reconciliation, and cross-app JWT SSO already knows where the sharp edges are. Cheaper teams typically cost more by month four.
Have you built a telehealth product before?
BoostFrame and BFEAI are not telehealth products. What transfers is the architecture: 7 production apps share a multi-tenant Postgres with row-level security; billing handles a Stripe subscription plus a dual-pool credit ledger reconciled against webhooks; cross-app SSO runs on custom JWT with refresh-token rotation. Those are the same primitives a telehealth SaaS needs for tenant isolation, visit-plus-subscription billing, and a single login across patient app, clinician app, and admin console.
What does a first engagement typically look like?
Usually a two-to-four week architecture audit or a single bounded build — a billing rework, a multi-state routing engine, an EHR integration, or a migration off a no-code prototype. We write a short engineering memo on what we found, what we'd ship, and what we won't. From there, we either continue into a build phase or hand the memo to your internal team.
Can you integrate with our EHR, e-prescribe, or labs vendor?
Most modern telehealth EHRs (Canvas, Healthie, Elation, athenaOne) and e-prescribe and lab vendors expose REST or FHIR APIs we can integrate against. We won't build a private interface to a legacy on-prem EHR — that needs a specialist integrations vendor. We will tell you up front which side of that line your stack sits on.
How do you handle PHI in development and staging?
Synthetic data only in non-production environments. Production-derived datasets get scrubbed through a deterministic anonymizer before they touch a developer laptop, and we prefer to do debugging against logs and reproductions rather than live patient records. If your team is already doing this differently, we adapt to your standard rather than impose ours.
Ready to see if this is a fit?
A 15-minute call. No deck, no slides. We talk about what you're shipping and where engineering is the bottleneck. Either way, you walk away with a senior engineer's read on your situation.