Woyce
Most of these are cheap to get right early and expensive to fix once you have live tenants and real PHI depending on them.
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.
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.
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.
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.
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.
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.
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.
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.
Per-tenant configuration, SSO, integration variety, and support tooling that lets non-engineers resolve customer issues.
SOC 2, data-residency options, contractual SLAs, and per-tenant customisation that does not fork the codebase.
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.
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.
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.
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.
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.