Scale vs. Localization

Run lifecycle across enough markets and you face the same fork on every campaign: build it once for everyone, or tailor it per country. The instinct, especially from local teams, is to tailor — each market is sure it’s special. Usually it isn’t, not in a way that changes the message. And every per-market version you create is a version you now own forever: another thing to test, translate, debug, and keep in sync the next time the offer changes.

So the default has to be global. One build, one logic, one source of truth — adapted in the cheap, automated ways that don’t fork the system: language, currency, local merchant names pulled from data, send-time tuned to the timezone. That’s not laziness; it’s the only way a small team operates many markets without drowning. I’ve held a lifecycle layer across seventeen countries and eight languages with this rule, and the rule is what made the surface manageable.

Global-first is a default, not a dogma. Two things genuinely justify a fork. The first is regulation: consent rules, channel restrictions, what you’re allowed to say about a price or a promotion, data-handling that differs by jurisdiction. You don’t negotiate with that; you build the exception and you build it properly. The second is operations on the ground: a market where the product genuinely works differently — different payment methods, different fulfilment, a holiday calendar that moves demand — so the global message would be wrong, not just imperfect.

Everything else — “our customers prefer a warmer tone,” “this image tests better here” — is a preference, not a requirement. Preferences get met inside the global build, as a variant or a parameter, not as a separate flow. The test for a real exception is simple: would the global version be wrong here, or merely not bespoke?

The danger isn’t the first exception; it’s the tenth. Each one looks reasonable alone, and together they quietly turn one maintainable system into seventeen fragile ones, where a change to the core campaign has to be re-implemented by hand in every market and breaks in three of them. The way you stay alive is to govern exceptions like spend: every fork needs a named reason — regulation or operations — an owner, and a willingness to delete it when the reason expires.

Treat the global build as the asset and each exception as a liability you’re choosing to carry. Centralize what can be centralized; localize only what genuinely can’t. The goal isn’t the same message everywhere — it’s the same machine everywhere, with deliberate, documented seams.

List every place your campaigns currently diverge by market. Against each, write the reason. Sort the list into two piles: regulation or operations forced this, versus someone preferred it. Collapse the preference pile back into the global build as variants. What’s left is your real localization surface — and it’s usually a fraction of what you’re maintaining today.

From then on, make global the default and put the burden of proof on the exception. New market, new campaign, new request to “make it special here” — the question is always the same: would the global version be wrong, or just generic? Build once for everyone; fork only where the law or the ground forces your hand. Your team stays small, your system stays sane, and the markets that truly need different treatment actually get it.