A super app is one application that hosts many services, often built by other teams, running as mini apps inside it. The user stays in one place; the host owns identity, payment and distribution.

The pattern is mature in Asia and increasingly attractive elsewhere, for an obvious reason: if you already have users who open your app daily, adding services looks like free revenue. Sometimes it is. More often it is a strategy that quietly makes a good product worse.

Interactive · 5 questions

The precondition nobody wants to hear

Super apps work when the host app is already something people open without being prompted. Not weekly. Not when they need it. Habitually.

That habit is the entire asset. It is what makes a second service inside your app cheaper to distribute than that service would be as its own download. If you do not have it, adding services does not create it — you get a bigger app with the same traffic and more surface area to maintain.

The uncomfortable version: if your retention is weak, a super app strategy will not fix it. It will give you more places for users to not come back to.

What the model genuinely gives you

  • Distribution leverage. A new service launches to an existing audience with an existing account and existing payment details. No install, no signup, no card entry — the three places funnels die.
  • Shared identity and payment. Build once, reuse across every service. This is a real and compounding engineering saving.
  • Third-party capacity. Mini apps let other teams build on your platform, so your catalogue grows without your headcount growing.
  • Data across services. Understanding a user across several contexts supports genuinely better recommendations — with the obvious caveat that this concentration of data raises the compliance stakes considerably.

What it costs, honestly

You are no longer building an app

You are building a platform, and platforms carry obligations apps do not: a stable SDK, versioning, developer documentation, review processes, sandboxing, support for people building on you. That work never ends, and it is largely invisible to your users.

One bad mini app damages your brand

Users do not distinguish between your app and something running inside it. If a third-party mini app takes payment and fails to deliver, they blame you. That means review and enforcement — which is a policy and staffing problem, not an engineering one.

Performance becomes a shared resource

Every mini app competes for memory, startup time and battery in your process. The host app that was fast at launch gets slower with each addition unless someone owns performance budgets and enforces them against teams who do not report to you.

Store rules constrain the model

Apple and Google both have positions on apps that host other apps and on how payment flows through them. This is navigable — plenty of super apps exist on both stores — but it needs deliberate design rather than discovery during review.

Concentrated data, concentrated risk

Aggregating behaviour across many services makes you a more attractive target and a more complicated one to govern. Under a regime like India's DPDP Act, consent gets harder when one login spans many purposes, and a deletion request has to reach every service that touched the user.

The middle path most teams should take first

The step between "single-purpose app" and "platform" is usually the right one, and it is much cheaper: add adjacent services you build and own, natively, inside your existing app.

You get most of the distribution benefit, none of the SDK and governance burden, and you learn whether users actually want more from you before committing to a platform. If two or three added services do well, the platform argument becomes evidence-based rather than aspirational. If they do not, you have saved yourself an enormous amount of work.

A reasonable test: if you cannot name three services your existing users have specifically asked you for, you are not ready to be a platform. Build the one they ask for most, natively, and see what happens.

If you are going ahead anyway

Some products genuinely should do this — marketplaces with strong habitual use, financial apps with daily engagement, logistics platforms where several roles share one account. If that is you, the things worth getting right before writing the SDK:

  • Decide the sandbox boundary first. What can a mini app read, call and store? Retrofitting a security boundary is close to impossible.
  • Set performance budgets on day one — startup time, memory ceiling — and make them a condition of publishing.
  • Write the review policy before the first partner. Enforcing rules that did not exist when someone built against you is how platforms lose developers.
  • Design consent for a multi-service world early, because a single bundled consent across many purposes is exactly what modern privacy regimes reject.
  • Instrument per mini app, so you can see which are earning their place and which are costing you performance for no return.

Frequently asked questions

A regular app does one thing. A super app hosts many services — often built by third parties as mini apps — behind one identity, one payment method and one download. The host provides distribution and infrastructure; the mini apps provide the services.
Scale matters less than habit. The precondition is that people already open your app without being prompted, because that habit is what makes a second service cheaper to distribute inside your app than as its own download. A smaller, genuinely habitual audience beats a larger, occasional one.
Yes — plenty exist on both. But both platforms have specific positions on apps hosting other apps and on how payments flow through them, so the model needs to be designed with those rules in mind rather than discovered during review.
Launching one when the host app is not habitually used. Adding services does not create engagement that was not already there, so teams end up with a larger, slower app, more code to maintain, and the same traffic they started with.
Yes, and most teams should. Add two or three adjacent services that you build and own natively inside your existing app. You get most of the distribution benefit without the SDK, sandboxing and governance burden, and you find out whether users actually want more from you before committing to a platform.