Why we built Tenelix

Walk into any mid-sized clinic and ask how the front desk, the billing room, and the consult rooms talk to each other. The answer is usually: they don't. A scheduler runs the calendar. An EMR holds the chart. A separate billing system issues invoices. And in between, a stack of spreadsheets glues it all together — manually, every shift, by people who'd rather be doing their jobs.

We built Tenelix because that arrangement is unfair to everyone. To the patient, who shows up to a system that doesn't recognize them across visits. To the receptionist, who copies the same name into three different applications. To the doctor, who has to leave the chart to look up a price. To the owner, who reconciles cash three days late because the spreadsheets disagree.

The core insight

The legacy story is that healthcare software has to be fragmented because the workflows are too different. We don't buy that. The workflows aren't that different — what's different is the tenant. A paediatric practice needs different fields than an oncology unit. A single clinic needs different deployment than a hospital group. A site in a region with no internet needs different infrastructure than a SaaS clinic.

So we built Tenelix as a single platform with per-tenant configurability — feature flags, JSON-driven forms, theming, role permissions — sitting on top of a hybrid multi-tenancy substrate. One codebase, three deployment modes:

• Standard — shared database with row-level isolation by tenant_id
• Enterprise (cloud) — dedicated database per tenant, audit-grade isolation
• Enterprise (self-hosted) — same Docker image, customer's own infra

The same code runs in all three. We change environment variables, not features.

What that buys you

When a clinic starts on Standard and grows into a hospital group, they don't migrate to a different product. They graduate their tenancy mode. When a regulator requires data residency, we ship them a Docker stack. When a specialty needs custom intake fields, they build them in the form builder — no fork, no migration, no waiting on the platform team.

We're early. The product is opinionated, the roadmap is public-ish, and we're building this in the open with our launch partners. If you're tired of checking three systems to answer one patient question, you're who we're building for.

What's next

Over the coming months we'll publish more on:

• The hybrid tenancy bootstrapper that lets sessions, cache, and queues flow into the right tenant database without code changes
• How we structured PHI access logging from day one
• Currency lock and why we treat it as a structural invariant, not a feature toggle

Subscribe via the contact page if you want these as they ship.