Back to blog
Behind the Scenes

Building a Global Platform for Pizza Hut: Lessons in Scale

February 15, 202410 min read

The Challenge

In 2018 I joined Pizza Hut Digital Ventures as a Senior iOS Developer to build one iOS platform that could ship across countries with different menus, payment systems, languages, and regulations.

It was my first time building at global scale.

The Architecture

White Label Approach

Every market needed the same core features, menu browsing, ordering, payment, order tracking, but varied locally:

  • Menus: differed by country, sometimes by city
  • Payment methods: cards in some markets, cash on delivery in others, plus GrabPay and Momo
  • Languages: and text directions (LTR and RTL)
  • Legal requirements: for data handling differed by jurisdiction

So we built a white label iOS framework with defined extension points for local customization.

Modular Framework Design

Independent modules, distributed via CocoaPods:

  • Core: networking, authentication, analytics, configuration
  • Menu: product display, customization, nutritional information
  • Cart: order management, promotions, pricing rules
  • Payment: payment gateway abstraction with pluggable providers
  • Tracking: order status, delivery tracking, push notifications
  • UI Kit: shared design system components

Each market's app was a thin shell: these modules, plus configuration and local implementations.

Configuration Over Code

Instead of branching on market in code, configuration drove behavior:

  • Feature flags controlled what was available in each market
  • Theming came from configuration files (colors, fonts, spacing)
  • Menu structures came from the backend, not the app
  • Configuration chose the payment provider

Adding a market meant a new configuration file and any local plugins, no core changes.

Challenges at Scale

Localization Beyond Translation

Translation is the obvious part. The rest:

  • Date and time formats: some markets use a 24 hour clock, others 12
  • Currency formatting: decimal separators, symbol position, rounding rules
  • Address formats: completely different between countries
  • Phone number formats: validation rules differ everywhere

Our localization layer handled all of it, not just strings.

Testing Across Markets

With 10+ markets on one codebase, a core change could break any of them:

  • Automated UI tests: for each market's critical flows
  • Snapshot testing: for UI consistency across configurations
  • Integration tests: against each market's staging API
  • A QA cycle: for each market before release

Regressions still slipped through: configurations times devices times OS versions was more than we could cover.

CocoaPods at Scale

Managing 20+ internal pods with interdependencies was painful:

  • Version conflicts between pods were common
  • Build times grew as the dependency graph expanded
  • Developers had to know which pod to change
  • CI/CD pipelines got complex across multiple pod repositories

Today I would look at Swift Package Manager for tighter Xcode integration, or a monorepo with Bazel or Tuist.

Team Coordination

The team was spread across offices:

  • Timezone differences: between development teams
  • Code ownership: who reviews changes to shared modules?
  • Release synchronization: markets had different release schedules
  • Documentation: keeping architecture decisions and API docs current

We handled it with weekly architecture syncs, code owners per module, ADRs (Architecture Decision Records) for significant decisions, and an internal wiki of integration guides.

Key Lessons

1. Design for Extension, Not Modification

Open/Closed held up at scale. When a market needed a feature, we extended through protocols and configuration instead of editing core code, so the core stayed stable.

2. Invest in Developer Experience

With 20+ developers using the framework daily:

  • Clear error messages: when configuration is wrong
  • Sample apps: showing how to integrate each module
  • Migration guides: when framework APIs change
  • Fast build times: we put real effort into compilation

3. Feature Flags Are Essential

We could not ship incomplete features or keep feature branches open for long. Flags solved both:

  • New features merged behind flags
  • Each market enabled features when ready
  • A/B testing was possible per market
  • Rolling back a feature needed no app release

4. Measure Everything

We needed data per market:

  • Performance metrics: app launch time, API response times
  • Crash rates: per market and OS version
  • Feature adoption: across markets
  • Build times: and CI pipeline duration

If one market had a 3x higher crash rate, we knew where to look.

5. Documentation is a Product

For a platform used by several teams, documentation was a product:

  • Time in each sprint for documentation updates
  • Architecture diagrams updated with every significant change
  • Changelogs for every framework release
  • Onboarding guides for developers joining any market team

Impact

During my time at Pizza Hut Digital Ventures:

  • The platform served **10+ markets** across Asia and the Middle East
  • Time to launch in a new market dropped from **6 months to 6 weeks**
  • App store ratings averaged **4.5+ stars** across markets
  • The shared codebase cut total development effort by an estimated **60%** versus separate apps

What I Took Away

Building for many markets is a different job from building for one:

  • Abstraction boundaries: what is shared and what is customized
  • Configuration over code: behavior driven by data
  • Developer experience: your framework's users are other developers
  • Testing strategies: the number of configurations demands automation

Those lessons carried into Jio Health, where we build a family of apps the same way.