Dentolize · Regional DB Split Walkthrough
On this pageThe headline, carefully framedWhat's genuinely useful for sales/marketing conversations laterWhat not to say yet

For Marketing

The headline, carefully framed

This PR is not a customer-facing feature launch. It's the infrastructure that makes a real launch possible: dedicated regional hosting, starting with Saudi Arabia. Nothing here should be announced as "new" to clinics — logins, dashboards, and workflows look identical. The only thing worth saying publicly, and only once it's actually live in production, is something like:

"Dentolize now hosts customer data in dedicated regional infrastructure, including a Saudi Arabia region, supporting local data residency requirements."

That's it. Resist the urge to describe multi-account switching, region lookups, or the migration tooling in customer-facing copy — those are enablers, not selling points on their own, and describing implementation details risks committing to specifics before the phased rollout (see scripts/GO_LIVE_RUNBOOK.md) is actually complete.

What's genuinely useful for sales/marketing conversations later

  • Data residency story for Saudi Arabia and future markets. This is the one concrete, defensible claim: clinic data for a given region can be hosted and stay within that region, rather than commingled with every other Dentolize customer worldwide in one shared database.
  • No feature regression. Every existing workflow — patients, appointments, invoicing, insurance, WhatsApp — is unchanged. This is a backend re-platform, not a redesign; there's no "we changed how X works" story to manage with existing customers.
  • A quiet but real UX improvement: users who juggle multiple clinic logins can now hold them side by side and switch instantly from the profile menu, instead of logging out and back in. This is small, but it's a genuine and demoable improvement if a specific customer asks about multi-clinic account management.

What not to say yet

  • Don't reference specific region names, hosting providers, or go-live dates in external material — those live in an internal runbook and can change.
  • Don't describe this as "faster" or "more scalable" without a specific, verified benchmark — this PR's stated purpose is data residency and blast-radius isolation, not raw performance, and no performance claim has been validated here.
  • Don't imply this is available today. It's unreleased; the runbook describes a careful, region-by-region migration of existing customers, not a flip-of-a-switch launch.