Turning one hospital's software into a business that sells to many.

The foundational call was tenant isolation via a separate MySQL database per hospital, provisioned automatically from the existing schema at signup — rejected the more common shared-database-plus-tenant_id approach on purpose. For medical and billing data, complete isolation matters more than the convenience of one shared schema: clean backup/restore/delete per customer, no risk of a query bug leaking one hospital's patients into another's report, and — not incidentally — a natural fit for the offline desktop app, where one database cleanly maps to one tenant's sync scope.

The trade-off, accepted deliberately: a schema change now has to roll out across every tenant database, not one, and connection handling has to scale with tenant count instead of staying a single fixed connection. Tenant routing followed the same "make it a real architectural decision, not a shortcut" pattern — subdomain-per-tenant (cityhospital.app.com) for the web app, and a registration-key pairing scheme for the desktop app, which has no subdomain to log into on first run.

The business layer — plans, billing, referrals — was built as its own Master Panel backed by a separate Master database, deliberately kept apart from every tenant database. A platform admin manages tenants, plans, and payments from one place that a hospital's own admin never sees, and that isolation is structural, not just a permission check.

The scariest-sounding problem going in was two front-desk PCs, both offline, both potentially generating the same receipt number. It turned out not to be a distributed-systems problem at all, once offline-create was designed correctly: a device never assigns its own patient ID or receipt number — it leaves that field blank locally and the server fills it in only once the record actually syncs. Two devices working offline simultaneously have nothing to collide over, because neither one is generating a number in the first place.

What was left to solve was narrower and more human: pure visibility, so the same patient doesn't get typed in twice by two different staff members who can't see each other's in-progress work. That became a small UDP broadcast on the hospital's local network — each offline device announces its pending records every ten seconds, tenant-scoped so two hospitals sharing a building don't see each other's patients, and self-filtered so a device doesn't confuse its own broadcast for a peer's. The result is a small "also being registered nearby" panel, not a distributed database.