Inside a Super-App: How a Regional App Onboards a Runtime Catalog

The asset a super-app already has

A regional super-app does not start from zero. Gojek's parent GoTo runs roughly 66 million annual transacting users, with GoPay alone at about 24 million monthly users and more than 2 million drivers across Indonesia and Singapore; Gojek itself cites 3 million driver-partners and 6.4 million merchants in the ecosystem. The Southeast Asia super-app market passed $58 billion in 2025 and is growing over 30% a year. The app already owns the daily habit, the identity, and the wallet. What it lacks is not users — it is breadth of services without rebuilding each one in-house.

The extension problem

Adding a new vertical the old way means a new team, a new backend service, new compliance, new maintenance — every service permanently on the core's books. That is why 2025 saw a "de-super-app" counter-trend in the region: instead of bolting on more first-party features, platforms opened the inside to third-party mini-programs. GoTo's GoBiz+ , launched in the first half of 2025, lets third-party micro-merchants build lightweight mini-apps with zero code and embed them in the main app. Reported retention for these mini-apps hit about 65%, versus roughly 40% for traditional in-app modules. The pattern borrows directly from China's WeChat mini-program ecosystem, where the host owns the shell and thousands of independent developers fill it.

The GoTo/Gojek playbook, dissected

Strip the GoBiz+ move to its mechanics and it is three decisions:

Layer	First-party build	Runtime catalog model
New service	Own team + backend + compliance	Third-party mini-program, platform-reviewed
Delivery	Ship in app update	Stream on demand, no full release
State	Core database grows	Sandboxed, isolated per mini-program
Reach	Limited by internal capacity	Bounded by catalog size

The host keeps what makes a super-app a super-app — one account, one wallet, one notification channel — and delegates the long tail of services to catalog entries. User phone storage is the hidden constraint that makes this attractive: average free space in the region is around 12GB, so "use-and-go" mini-apps that never install a full app fit local habits better than another heavy download.

What a runtime catalog actually provides

A catalog is only as good as the runtime underneath it. The runtime must give every entry: a sandboxed execution boundary so one mini-program cannot read another's data or the host's; a uniform API surface (the wx.* family) so a program written once runs across every host that ships the runtime; and a governed distribution path — submission review, content security, abuse controls — so the host is not liable for whatever a third party ships. Without that substrate, "open the app to partners" is just "run untrusted code in our most trusted surface," which no compliance team will sign off.

The portability multiplier

Here is the multiplier that changes the math: if the runtime is generic and speaks the same grammar as the proven Chinese mini-program ecosystem, then a mini-program already validated by hundreds of millions of users in China can be ported into a GoTo, a Grab, a Rappi, or a bank app without a from-scratch rebuild. The host gets catalog breadth overnight; the developer gets distribution across many apps from one codebase. Cross-border portability is the whole point — the catalog is an import channel, not a local-only build.

Where Cross Mini App fits

Cross Mini App is the generic runtime plus the open catalog. For a regional super-app, that means onboarding third-party services the GoBiz+ way — reviewed, sandboxed, streamed — but with a grammar portable enough to import mini-programs proven elsewhere. The host keeps its account and wallet; the catalog brings the long tail. You extend a super-app without rebuilding it, and you do it with a catalog whose entries are portable across every app that adopts the same runtime.