Multi-tenant SaaS

Multi-tenant dental practice management and patient engagement SaaS

A cloud platform for dental and orthodontic groups that run many locations and need one system for the full patient lifecycle, from first booking to recall, without letting any location see another's data.

Our BAA offer

Built forDental and orthodontic networks

Team shapeAround 7 people: architect, 3 engineers, QA, designer, delivery lead

TimelineAbout 7 months to the first multi-location release

The problem

The group ran each franchise on a different tool. Reporting took days, onboarding a new location took weeks, and the owners could not prove that one location's patient data was separate from the next. Their legacy vendor shared one database for everyone.

How we approached it

We designed the platform around tenant isolation first. Every location is a tenant with its own database, credentials and encryption keys, created by an automated onboarding job. On top of that sit four roles, each with a different surface: super admins for the network, clinic managers, practitioners and patients. Patients get a portal and AI generated onboarding and aftercare videos so front desk teams stop repeating the same instructions.

What we built

Isolated database per franchise location, created and migrated by a control plane
Role based access for super admins, clinic managers, practitioners and patients
Multi-factor sign-in with short lived JWT access tokens on REST APIs
Conversational assistant and AI generated videos for onboarding and post-operative instructions
Appointment scheduling, treatment plans, billing cycles and insurance verification workflows
Network wide reporting that reads from per tenant data without moving it into one shared store

Architecture

How the pieces fit together

1Patients and staff

2Laravel API and tenant router

3Tenant database A, B, C

4Encrypted storage and queues

Tenant control planeA small central database holds tenants, plans and feature flags. It never stores patient data.

Request pipelineEach API call carries a signed token. Middleware resolves the tenant, switches the database connection and rejects anything that cannot be resolved.

Background workRedis queues run recalls, reminders and billing jobs per tenant, with retries and dead letter handling.

Files and mediaImages and videos sit in encrypted object storage under tenant specific prefixes and keys.

Safeguards built in

Security and compliance controls

Separate database and keys per tenant
Append only audit log of every record access
Enforced MFA for staff, rate limited patient sign-in
Per tenant backups and tested restores
PHI-free staging environments

What changed

Outcomes for the operator

New locations go live from a checklist instead of a project, because onboarding is automated.
Owners can answer a regulator or a franchise buyer about data separation with architecture, not with a promise.
Front desk staff spend less time repeating instructions because patients receive them in their portal and by video.
Network reporting works without copying patient data into a shared warehouse.

Technology

LaravelMySQLRedisJWTReactAWS S3Supervisor

Integrations

Insurance eligibility APIsPayment gatewayEmail and SMS providersCalendar sync

Representative engagement. Client details and internal figures are withheld under NDA. Compliance depends on how a system is operated as well as how it is built, and your own counsel decides what applies to you.