Founders come to me wanting to build "a doctor booking platform for the US, UK and Europe," and they picture one product with a few translated labels. That is the mistake, and it is an expensive one. A doctor booking platform is not language-portable; it is regulation-portable and payer-portable, which is to say barely portable at all unless you design for it. The search, the availability engine and the booking flow travel fine. The insurance model, the payment rails and the compliance layer do not. Build one spine and three regional adapters, and you have a platform. Build one region and hope it stretches, and you have a rebuild.
The Three-Region Compliance Spine
Here is the architecture I sketch on the whiteboard in the first meeting. I call it the Three-Region Compliance Spine. The spine is everything the regions share. The ribs are the parts that must be different per market. Getting the split right is the entire game.
Who pays: the payer model changes everything
The deepest difference between these markets is not language, it is who pays the bill, and that reshapes the product. In the US, patients shop for providers who are in-network for their specific insurance plan, so insurance matching becomes a first-class search filter and a serious data problem: you have to model plans, networks and coverage and keep them current. In much of the EU, public systems and mixed payers mean the insurance-shopping step matters far less, so search leans on specialty, location and access instead. The UK sits in its own place, an NHS-context public system running alongside a private sector, so a platform often has to serve both and keep their data cleanly separated. Force one region's payer assumptions onto another and the product feels wrong to every patient who uses it.
Payments follow the payer
Because the payer differs, so do the money flows. A US platform may deal with co-pays, insurance verification and patient billing. A private-pay booking in the UK or EU is a straightforward payment; a public-system booking may involve no patient payment at all. This is why payments belong in the regional module, not the shared core. You want one booking engine that can call whichever payment and billing flow the region requires, rather than a payment system with US assumptions baked into its bones. This modular approach is the same discipline we bring to any custom software build where one product must serve several markets.
What everyone gets wrong: "compliance is the same everywhere, just tighter in the EU"
I hear this constantly, and it leads people to build for the loosest region and plan to "tighten up for the EU later." That is backwards and dangerous. HIPAA, GDPR and UK-GDPR overlap in spirit, protect health data, limit who can access it, log everything, but they differ in specifics that touch your architecture: how consent works, how long you keep data, where data may physically live, what a patient can demand you delete, and how you prove all of it. Data residency alone can force region-scoped storage that you cannot cleanly add after the fact. The right move is the opposite of "loosest first": build one strong compliance baseline that satisfies the strictest common denominator, then layer each region's specifics on top. We go deep on how to structure that baseline in healthcare app security and compliance. Retrofitting compliance after launch is the most expensive rework in this entire category, and it is entirely avoidable.
One baseline, three sets of specifics
The practical way to hold three regimes in one product is to build a single strong baseline that satisfies the strictest common requirements, then add each region's specifics as a thin layer on top. The baseline covers what all three demand in spirit: encrypt health data, restrict access to who genuinely needs it, log every access, obtain and honor consent, and be able to prove all of it. On top of that baseline you layer the specifics that differ: US HIPAA handling of protected health information, EU GDPR treatment of health data as a special category, and UK-GDPR alongside NHS-context rules. The baseline is shared engineering; the specifics are per-region configuration and policy. Build it the other way round, specifics first with no common baseline, and you get three subtly incompatible systems that are miserable to keep in sync.
Tell us what you have in mind. We turn AI prototypes and fresh ideas into shipped, scalable products, from India, for the US and UK.
One codebase, region-aware
Almost every founder eventually asks whether to run one codebase or several. My answer is nearly always one codebase with region-aware modules. Three separate codebases feel cleaner on day one and become three diverging products by month six, tripling your maintenance and letting bugs fixed in one region survive in the others. A shared core with swappable payer, payment and compliance modules gives you the isolation where it matters (compliance, data residency) without the cost of maintaining triplets. The rare exception is a market whose rules are so unusual that isolating it is genuinely simpler, and even then I would isolate the module, not fork the whole platform.
How we build multi-region: AI-amplified, human-hardened, one region at a time
Our process fits this problem well. In the early phases we lean on AI to move fast: mapping the shared core, drafting region-specific data models, generating UI concepts and turning approved designs into clean front-end code, and documenting the compliance requirements per market so nothing is discovered late. That conceptualization-and-prototyping speed is real and it is where the timeline compresses.
Then the humans take over for the parts that carry legal and financial weight: the availability engine, the payment integrations, the residency-aware data architecture and the compliance controls. We build compliance and security in from day one, not as a pre-launch scramble, and we test every integration with mock bookings across each region before anyone real logs in, because an integration that "looks connected" but was never exercised end to end is exactly how launches break. And then we make a recommendation founders do not always expect: launch one region first. Being tech-ready for three markets is not the same as being operationally ready. Do you have providers signed up, local support, and marketing in each region? If not, you win one market, prove the model, and add the others as adapters. We lay out that sequencing in how to launch across the US, UK and EU.
The build order for a multi-region platform
- One region, fully: pick the market where you have real provider supply and launch there first.
- Compliance baseline: build to the strictest common denominator, then add regional specifics as modules.
- Shared core: search, availability engine, booking, reminders and reviews, region-agnostic by design.
- Regional adapters: payer model, payments and residency-aware storage per market.
- Expand as adapters, not rewrites: each new region is a module and an operations effort, never a new codebase.
Deciding between copying an incumbent, licensing one, or building this yourself is a real strategic question, and we walk through it honestly in Zocdoc vs Doctolib vs build your own. When you are ready to scope the spine and the adapters against your actual target markets, that is exactly what our product development team does first, before writing a line of the patient app.
Frequently asked questions
What is a doctor booking platform?
A doctor booking platform is a two-sided marketplace where patients search for providers, see real-time availability, and book appointments, while providers manage their calendars and fill empty slots. Zocdoc is the well-known US example and Doctolib the European one. Building one for multiple regions means one core engine adapted to very different insurance, payment and data-protection rules per market.
Can one platform serve the US, UK and EU?
Yes, but not as a single copy-pasted build. The core (search, availability engine, booking, reminders, reviews) is shared, while the payer model, payment flows and compliance layer are region-specific modules. Think one spine, three regional adapters. Trying to force one region's assumptions onto another, US insurance logic onto the NHS, for example, is the classic way these builds break.
How does US insurance change the build?
Heavily. US patients filter by whether a provider is in-network for their specific plan, so insurance matching is a first-class search filter and a data problem in its own right. The platform has to represent plans, networks and coverage, and keep them current. This is largely absent in single-payer or public-system markets, which is why US search feels so insurance-centric.
How is the UK different from the US and EU?
The UK combines NHS-context public healthcare with a private sector, so a booking platform often has to handle both worlds and respect NHS data rules alongside UK-GDPR. The insurance-shopping step that dominates the US matters far less; the emphasis shifts to appointment access, referrals and clear separation of public and private data. It is its own model, not a lighter US.
What compliance rules apply in each region?
In the US, HIPAA governs how you handle protected health information. In the EU, GDPR applies, with health data treated as a special category needing extra protection. In the UK, UK-GDPR applies alongside NHS-context data rules. These overlap in spirit (protect health data, limit access, log everything) but differ in specifics, so you build one strong baseline and layer regional requirements on top.
Should I use one codebase or separate ones per region?
One codebase with region-aware modules, in almost every case. A shared core keeps you from maintaining three diverging products, while payment, payer and compliance modules swap in per region. Separate codebases multiply your maintenance cost and let the regions drift apart. The exception is a market with requirements so unusual that isolation is genuinely simpler, which is rare.
How much does a multi-region platform cost to build?
More than a single-region build, because each region adds a payer model, payment integration and compliance layer, but far less than three separate platforms if you share a core. The honest approach is to launch one region well, prove the model, then add regions as adapters. Any firm number before scoping the per-region modules is guesswork.
Can appico build a multi-region healthcare platform from India?
Yes. We build the shared core and the region-specific payer, payment and compliance modules for the US, UK and EU, from India, at a fraction of onshore cost, with compliance designed in from day one and the code and accounts in your name. We recommend launching one region first, then expanding, because operational readiness per region matters as much as the technology.
“Disciplined, committed, over-delivers. Three years in, I would re-hire any day.”
“A factory of ideas.”
“A fantastic-looking and performing website.”
Talk to the team, we reply within 24 hours, and the first consultation is free.
Start a conversation →