The six decisions that shape a healthcare SaaS
Most of these are cheap to get right early and expensive to fix once you have live tenants and real PHI depending on them.
Tenant isolation for PHI
The decision that is hardest to reverse. Shared-schema with row-level scoping is cheaper to run; schema- or database-per-tenant is easier to defend in a security review and easier to unwind when a customer leaves. We pick deliberately, in writing, before the first migration — because changing it later means migrating live patient data.
Per-organisation roles and permissions
Provider groups have hierarchies — practice, location, department, individual clinician — and permissions follow them. Retrofitting that onto a flat role model means rewriting every authorisation check in the product.
Audit trails that are tenant-scoped
Each customer needs to see their own access logs without seeing anyone else's. Designed in, this is a query filter; bolted on, it is a data-modelling exercise across the whole application.
Onboarding without an engineer in the loop
Every new clinic means users, locations, integrations, and templates. If onboarding needs engineering, growth is capped by your team's calendar — and that ceiling arrives sooner than most teams expect.
Billing that matches how healthcare buys
Per-provider, per-location, per-encounter, or a platform fee — healthcare rarely buys per-seat like ordinary SaaS. The pricing model shapes the data model, so it is worth settling early.
A configurable compliance posture
Enterprise customers arrive with their own retention policies, SSO requirements, and data-residency constraints. Making these per-tenant configuration rather than code is what lets you say yes without a fork.
What to build at each stage
- 01
MVP — one design partner
One clinic, one workflow, real usage. The goal is a product a design partner will not give up, not a platform. Multi-tenancy is designed in but not yet exercised.
- 02
First paying customers
Self-service onboarding, billing, and the compliance documentation your first enterprise buyer's security review will ask for. This is where products with a weak tenancy model start paying interest.
- 03
Scale — many organisations
Per-tenant configuration, SSO, integration variety, and support tooling that lets non-engineers resolve customer issues.
- 04
Enterprise
SOC 2, data-residency options, contractual SLAs, and per-tenant customisation that does not fork the codebase.
Healthcare SaaS FAQs
What does healthcare SaaS development cost?+
It depends entirely on scope and integration surface, so we scope before quoting rather than publishing a number that will be wrong for your case. What we can say is that the compliant baseline and the first EHR integration are consistently the two largest line items in a v1, and both are underestimated more often than anything else.
Should we build multi-tenant from day one?+
Design for it from day one; do not necessarily build all of it. Getting the tenancy boundary into the data model early costs little, while adding it later means migrating live PHI — which is as unpleasant as it sounds. Self-service onboarding and per-tenant configuration can wait until you have customers who need them.
How do we handle different EHRs across customers?+
It is a per-tenant configuration problem as much as an integration one. Each customer's adapter, credentials, and field mappings are scoped to their tenant and selected at runtime, so onboarding a new customer's EHR does not mean a deploy or a fork of the codebase. The adapters themselves are the same integration work our FHIR and EHR integration practice does for any single build; what a SaaS product adds is keeping that per-tenant surface isolated and swappable while everything else stays shared.
When do we need SOC 2?+
Usually when the first enterprise customer asks, which tends to be earlier than teams plan for. If you are selling to hospital systems or large provider groups, assume it will come up during the first serious procurement conversation.
Can you take over an existing healthcare SaaS product?+
Yes. We start with an architecture and compliance review so both sides know what we are inheriting, then agree a remediation and roadmap sequence. Tenancy model and audit logging are the two areas where inherited products most often need work.