Operating one platform across 15 jurisdictions

There's a particular flavor of regret a regional VP of engineering reaches a few months after launching their first cross-country platform. The code works. The team tried. But what looked on the deck like "one product, fifteen markets" has quietly turned, in production, into fifteen products sharing a logo. The currency mismatches were obvious from week one. The tax handling unraveled three months later. The contract templates fractured the first time an Argentine customer asked about UVA-indexed clauses. And the analytics layer, which was supposed to unify the regional book of business, gave six different answers to the same question depending on which country GM you asked.

We have watched this pattern play out half a dozen times across Latin America. The cost of getting it wrong is high. The cost of getting it right early is small. And the choices that determine which path you are on are surprisingly few — most of them made before anyone writes a line of code.

What "one platform" actually means

Most teams answer this question with infrastructure. One AWS organization, one CI pipeline, one design system, one analytics warehouse. Those answers are necessary but not sufficient — and the teams that stop there are the ones that end up shipping fifteen products. The harder question is operational: which decisions does the platform make for everyone, and which does it expose to each country?

The pattern that holds up: one platform means one data model, one identity system, one observability backbone, and a single way to model variation. Everything else can — and probably should — be country-specific.

Teams who get this right invest early in a clear contract between the platform and the country. The platform owns the data model, the deployment pipeline, the security boundary, and the analytics layer. Each country owns its workflows, its tax and regulatory behavior, its contract templates, and its language. The boundary between them is explicit: a country team can extend a workflow, but it cannot fork the data model. The platform team can ship a new field, but it cannot change the meaning of an existing one.

That contract is usually informal at first. The teams who survive year two write it down — and treat it as a real interface, with versioning and a deprecation policy. The teams who do not end up with what one CTO we worked with called "fifteen branches of one product, run by sixteen people."

The four axes of variation that actually matter

Most cross-border platform conversations get tangled in surface-level differences. What we have found, across actual deployments, is that the variation that drives architecture decisions clusters tightly onto four axes.

Currency and price discipline come first. Argentina alone forces a real conversation: multiple official and unofficial exchange rates, capital controls that shift quarterly, and inflation-indexed contract units like UVA and CER that are not strictly currencies but behave like them. Chile contracts widely in UF — an inflation-indexed unit of account the platform either understands natively or papers over forever. Brazilian price tables move with the IGP-M index. A platform that treats currency as a primitive scalar will accumulate corrections without end. A platform that treats currency as a compound concept — unit of account, FX timestamp, indexed-amount support — absorbs new markets cheaply.

Tax and invoicing is the axis most teams underestimate. Mexico's CFDI 4.0 electronic invoicing, with its tax-authority pre-approval flow and digital signing requirements, is structurally different from Colombia's e-invoicing under DIAN, which is structurally different from Brazil's NFS-e, which itself varies by municipality. A team whose invoicing layer was built around the U.S. assumption of "generate PDF, send email" discovers this in production — which is the most expensive place to discover it.

Contract and dispute is third. Each jurisdiction carries its own contract law conventions, signing requirements, and dispute-resolution defaults. Mexican commercial law requires specific clauses for arbitration to bind. Argentine consumer-protection law has aggressive defaults that drafters routinely miss. Brazil's CDC is a different planet. Country-versioned contract templates are not polish; they pay for themselves the first time a customer disputes.

Language and locale is fourth, and the easiest to get wrong by treating as a single problem. Spanish across the region varies enough to be noticed — Mexican "tú" versus Argentine "vos" versus peninsular Spanish — and Brazilian Portuguese is its own language, not a Spanish dialect. The platforms that work treat locale as a compound: country plus language plus currency plus tax regime plus contract template. The platforms that do not eventually fragment the user experience and the operational backend at the same time.

The architectural insight is that these four axes are independent. A workflow can vary on currency without varying on contract. A country can vary on tax without varying on language. The platform that models them independently is the platform that absorbs new markets cheaply.

The architectural pattern that holds up

The shape that survives contact with fifteen markets is, in our experience, three layers.

A canonical data layer that is strictly normalized, country-agnostic in its core entities, and that carries explicit context fields — country, currency, regulator, language — on every row that needs them. This is the layer the platform owns. It changes carefully and deliberately, with versioning and a stated compatibility policy.

A policy layer that interprets country-specific rules and applies them to the canonical data. Tax calculation, invoicing format, contract template selection, regulatory deadlines, payment terms — all live here as configurable, versioned rules per country. This layer is shared across countries but parameterized, and country teams own their own rules within the parameters the platform exposes.

A presentation layer that is free to be country-native. Workflows, terminology, screen flows, even default behaviors can differ. The single constraint is that everything the presentation does ultimately writes to the canonical data layer through the policy layer.

This shape has a few important properties. It scales by adding policy rules and presentation flows, not by forking core code. New countries onboard in weeks because the platform team and the country team know exactly what each one owns. And when something does go wrong — a currency redenomination, a new tax regime, a regulatory shift — the fix lands in one place, not fifteen.

The pattern is not new. Variants of it show up in Salesforce's multi-org model, in SAP's company-code hierarchy, in every enterprise B2B platform that survived its first decade. What is new — what the regional Latin American business demands — is doing this without the buy-in of a global head office or the time horizon of an enterprise rollout. The pressure to be regional, fast, and lean pushes the architectural conversation forward by several years.

Where convergence pays — and where it doesn't

The temptation, once the platform exists, is to converge everything. One contract template. One pricing model. One operating process across the region. Resist this temptation selectively.

Convergence pays where the variation is incidental — different file formats, different rounding conventions, different naming for the same thing. These differences exist because no one ever decided otherwise. Make a decision, document it, retire the old behavior. The country teams usually thank you.

Convergence does not pay where the variation is structural — different tax authorities, different contract law, different consumer-protection regimes, different currency mechanics. These differences exist because they have to. Trying to converge them creates either a platform that breaks in production or a country exception that lives forever.

The trick is telling the two apart. A useful heuristic: if the difference is enforced by a regulator, a court, or the underlying economics of a market, it is structural — leave it alone. If it is enforced only by habit, it is incidental — bring it in.

Surface this in the data. Every place the platform allows variation, log what each country chose and how often each variant is exercised. The leadership team should be able to see, at a glance, which differences are paying for themselves and which are simply accumulated habit. The decisions get easier when the numbers are visible.