Super App Skeleton: How Muze Built the Infrastructure Behind TrueID's 20M+ Users and 20+ Business Units

Building a Super App isn’t hard because it needs many features.

It’s harder because those features come from different teams — with different business goals, different release cadences, and sometimes running across multiple device generations simultaneously.

When Muze worked with TrueID to support 20M+ Monthly Active Users and more than 20 Business Units on a single ecosystem, the real challenge wasn’t “build all the features.” It was “design the structure so every team can grow without breaking the system.”

Scale That Changes Every Decision

These numbers aren’t just impressive stats — they change every architectural decision, from how Muze structured the codebase to which tradeoffs were worth making.

The Real Problem: 20 Teams Living in the Same House

Before writing a single line of code, the key thing to understand is that TrueID isn’t a regular app. It’s a digital platform spanning Streaming, Music, Games, News, and True Services under one brand.

Each BU wants its own campaigns, its own region-specific content, and the freedom to move fast on its own business priorities — while users must feel the app is seamless and unified.

Without a shared structure, the result is a monolithic app that becomes harder to control the bigger it grows — every new feature risks breaking something else.

That’s the core problem Muze was brought in to solve.

Skeleton-First: Muze Didn’t Start With Features

Muze’s approach was to start with an App Skeleton — not “what features does each BU need?” but:

“What kind of shared structure does this app need so BUs can plug in their own features without fragmenting the codebase?”

The Skeleton covers navigation structure, shelf engine, CMS integration, authentication layer, feature toggles, payment integration, entitlement logic, design system, and module boundaries between services.

When the Skeleton is solid, adding a new BU isn’t an ad-hoc extension — it’s plugging a module into structure that was built to receive it.

3 Technical Decisions — and Why Muze Made Them

1. 32-bit APK for All Hardware Generations

TrueID TV Box spans 3 generations with very different capabilities — from Gen 1 with limited specs to Gen 3 with AI and Camera.

One option was separate APKs per generation. That sounds manageable at first, but means duplicated maintenance cost for the lifetime of the project.

Muze chose to build a single 32-bit APK that works across all generations. One codebase = one test path = one deployment — reducing the risk that features behave differently across device versions.

The tradeoff: the performance layer needs to work well on both low-spec and high-spec hardware. Muze handled this through feature detection and adaptive rendering rather than hardcoding per device version.

2. JSON-Driven UI + Firebase Remote Config Instead of Waiting for App Releases

Business teams need to change layouts, launch campaigns, or adjust content per region quickly — without waiting for the app store submission cycle.

Muze designed the Home Page to use a JSON Skeleton Structure that determines layout at runtime from the backend, rather than hardcoding it in the app. Combined with Firebase Remote Config to control feature availability by hardware generation and region.

The result: business teams can change shelves, hero banners, grids, or toggle features from the CMS — no app release required.

The risk with JSON-Driven UI is consistency: without guardrails, the app can end up with broken layouts. Muze addressed this with schema validation at the CMS level so invalid layouts never reach production.

3. Adapter Pattern for Multi-Provider Auth and Payment

TrueID connects to multiple payment providers — True Money (TMN) and TikTok Beans — plus Netflix entitlement and True’s own membership system.

Each provider has different flows, token formats, and error handling. If provider-specific logic is tied directly to the core app, adding a new partner or switching a provider touches the core codebase.

Muze designed an Abstract Interface for Auth and Payment: the core app only knows it needs to “authenticate” or “process payment” — it doesn’t know the details of any specific provider. Each provider gets its own adapter implementation.

The result: adding a new payment method means writing a new adapter — core logic stays untouched.

Android TV: Harder Than Anyone Expected

Many assume a TV app is just a mobile app on a bigger screen. In practice, the challenges are fundamentally different.

On mobile, users tap what they want directly. On TV, users navigate with a remote — every up, down, left, right press must feel natural.

The real problem encountered on this project: a Home Shelf with multiple content types (hero, rail, grid, recommendation) caused focus to jump to the wrong position when moving between shelves with different layouts — making the app feel unresponsive.

TrueID TV also had to run at the System Launcher level of Android — meaning it manages Boot sequence, Splash Screen, and Hardware connections via AIDL, beyond what a regular app handles. These are the kinds of constraints that Discovery phase needs to surface — not surprises during development.

Discovery-First: Why Muze Didn’t Start Coding Immediately

Before modernizing the TrueID TV Launcher, Muze performed a module-by-module Legacy Codebase Audit to determine what should be reused, what should be replaced, and what the highest-impact dependencies were.

Why Discovery first: a system with 20M+ MAU has no room for “try it and fix later” like a startup — if migration disrupts experience mid-flight, the impact is measured in millions of users.

Good Discovery here meant going deep on hardware constraints across device generations, integration points with multiple partners, content delivery paths, and entitlement logic hidden inside the existing system.

The clearest lesson from this project: the bigger the system, the less you should rush to code. Discovery is the cheapest form of risk mitigation.

Lesson Learned: Skeleton Isn’t Overhead — It’s Speed

Many organisations see investing in infrastructure before building features as wasted time. But from the TrueID project, what became clear is that BU 21, 22, 23 came onboard significantly faster — because the structure was already ready for them.

Without a Skeleton: every new BU has to negotiate with the existing codebase, and every new feature adds unchecked complexity.

For organisations building digital platforms: if you plan to grow beyond 5 BUs, ask whether today’s architecture can support that growth — the answer will tell you when to start building the Skeleton.

Key Takeaways

• Super App = Infrastructure, not a Feature List — internal structure determines how far the platform can grow
• One 32-bit APK beats multiple APKs — when targeting multiple hardware generations, backward-compatible builds reduce long-term maintenance cost
• JSON-Driven UI + Remote Config = business agility without release cycles
• Adapter Pattern means adding a new payment or auth provider doesn’t touch core logic
• Android TV ≠ Mobile on a big screen — Focus Management and System Launcher integration are fundamentally different engineering domains
• Discovery before Code — for systems with large user bases, auditing before migrating is cheaper than fixing after go-live

See more Muze case studies →

Talk to the Muze team →

From Muze’s experience designing and modernising TrueID Super App and Android TV Launcher 2026