Case study 04 · Platform & scale

What to standardize — and what to leave to each market

A shared global template — design, application, and middleware — built to scale across markets and brands, starting with a single live deployment in the Philippines.

The strategic question

Every new market or brand on the platform could, in theory, get its own independent, white-labeled build. That's not the wrong answer — for a market with the scale and local team capacity to run its own roadmap, building independently can be exactly right. There's no single correct answer here in the abstract; it depends on that market's needs and readiness. The question I actually had to answer was narrower: given where this platform and its markets stood right now, which parts genuinely needed to be identical everywhere, and which had to differ because the market actually was different?

The constraint

No two markets behave the same way. Payment methods, promotion mechanics, delivery expectations, and even how customers browse a menu vary by country and sometimes by brand. None of the markets on this platform were yet at the scale or local-team maturity where a fully independent, white-labeled build would pay for itself — that's a real path, just not the one this stage called for. Building everything independently now, before that independence was earned, would have meant duplicated engineering and drifting design language for markets that didn't need it. At the same time, a template that's too rigidly shared breaks the moment a market needs something it doesn't support. One that's too loosely shared just becomes several codebases wearing the same name — all of the maintenance cost, none of the leverage.

The decision I owned

I led the architecture and feature-prioritization calls with engineering on what belonged in the global template versus what stayed local — and worked directly with regional teams to understand each market's constraints and customer behavior before drawing that line, not from a spec sheet alone.

The template spans three layers: the design system, the application, and the middleware API. Promotions are the clearest example of the split in practice. Core promotion mechanics — the generic kind, like a percentage discount or a bundle deal — are built once at the global level and reused everywhere. Promotion types specific to a market's regulations or marketing calendar are built as local customizations layered on that shared base, not forked copies of it.

The outcome

The Philippines is the platform's first live market on this architecture. The template is built to scale to additional markets and brands, and that expansion is in progress — I don't have a second live market to point to yet. What I can point to is the discipline itself: every feature decision runs through the same global-versus-local question before it ships, so the foundation isn't quietly accumulating one-off exceptions it will have to unwind later.

What I'd tell another product leader

"Build it once" isn't a technical call — it's a product one: deciding what has to feel identical everywhere, and what has to differ because the market actually does.

Get that call wrong in either direction and you pay for it later: too shared, and you're patching the same rigid template forever; too local, and you're maintaining several platforms that happen to share a name.