The anatomy of a super app, and whether you should build one

Almost everything written about super apps is a list. The top ten in Asia, the five most successful cases, the features you need. Lists are easy to write and they teach nothing, because the feature list of a super app that worked and one that failed are close to identical. Both have a wallet, a marketplace, a chat, a booking flow and a rewards program. The difference is not in the list.

This article is about the structure underneath, which is where the difference actually lives. A super app is a host application that people open out of habit, carrying a way to pay and a verified identity, that exposes a runtime other companies can build services inside. Four layers, and only the top one shows up in a feature comparison. The named platforms appear here as evidence for that structure rather than as a countdown, because MoMo, ZaloPay, WeChat and AirAsia reached the same position from four genuinely different starting points, and what they did differently is more instructive than what they have in common.

It is also worth saying early that most companies asking this question should not build one. That is not a rhetorical hedge. There are two preconditions, they are measurable from analytics you already have, and if you do not meet them then adding services to your app is a way of not addressing the reason nobody opens it. The last section is a test you can apply in about ten minutes, and a fair number of readers will finish it having decided to do something else, which is a better outcome than a year spent building tab four.

A note on what this article is not. It does not price anything and it names no user counts, valuations or market sizes, because those numbers are the least reliable part of everything written on this topic and the argument does not need them. If you are at the point of costing a program like this, the guide to software development cost covers how to think about the estimate. What follows is the structure, which is the part that decides whether the estimate was ever worth producing. Our own super app development services page covers the commercial side if that is what you came for.

A super app is not a bundle of features, and the difference is structural

Start with the thing that gets missed. If a super app were a collection of services in one binary, then any company could become one by shipping enough tabs, and the strategy would reduce to a roadmap. Plenty of companies have tried exactly that. They ship a wallet, then food ordering, then bill payment, then a marketplace, and after four releases they have a larger app with the same daily active users and a support queue that now spans four domains nobody on the team understands.

What separates the platforms that worked is that they stopped writing the services themselves. The host application provides four things that are expensive and boring: a verified identity, a way to move money, a notification channel and a support path. Then it exposes those four to other companies through a constrained runtime, and other companies write the services. The host is not competing on features at that point. It is competing on how attractive it is to build inside, which is a completely different business.

That reframing has a consequence you can feel in the roadmap. In a bundle, every new category costs a release cycle, a team, and permanent ownership of a domain you did not previously understand. In a platform, a new category costs a review slot and a shelf position. The first model scales with your headcount. The second scales with how many other companies want access to your users, and there is no version of your hiring plan that competes with that.

This is also why the word super is misleading and the word host is better. The interesting property is not that the app does many things. It is that the app is the place other things happen, which is a position rather than a feature set. Positions are defended differently from features: you defend a feature by shipping a better one, and you defend a position by being the cheapest place for a partner to reach a paying customer.

The two mental models, side by side

Do this

• Ask what a partner gets by building inside youIdentity they do not have to verify, payment they do not have to acquire, a user who is already there. If the answer is thin, the runtime will be empty whatever you build into it.
• Treat the four shared services as the productIdentity, payments, notifications and support are what you sell to partners. Making them genuinely reusable is harder and worth more than any feature above them.
• Count daily opens before counting servicesThe platform is worth something in proportion to how often the host is opened. That number is the multiplier on everything else, and it is the one you cannot ship.

Not this

• Ship categories until something sticksEach one adds a domain to own, a support surface and a screen nobody visits. Four unloved tabs is not a platform, it is four unfinished products in one binary.
• Copy the feature list of an app that workedThe list is the output of a position they already held. Copying the output while lacking the position gives you the list without the result.
• Assume partners will come because you askedA merchant chooses between building inside your app and buying an ad. Yours has to be cheaper per acquired customer, and that is a number they will actually check.

The vocabulary, because these words get used loosely

Host application

The app the user actually opens and has a habit around. It owns the entry point, the account and the navigation. Its opening frequency is the ceiling on everything built inside it.

Mini app

A service built by somebody else, running inside the host under a restricted runtime rather than installed separately. The user experiences it as a screen in the host, not as an app.

Runtime and sandbox

The constrained environment mini apps execute in, plus the rules about what they may touch. The sandbox is what makes it safe to let a stranger ship code inside your app.

Permission scope

A specific capability a mini app may request, such as reading a verified name or initiating a payment. Scopes are the contract between host and partner, and reviewing them is most of what a platform review team does.

Shelf position

Where a mini app appears in the host: on the home screen, in a category list, or only via search. This is the real currency the host has to trade, and it is scarce by definition.

Payment rail

The mechanism that moves money, including settlement to partners and the refund and dispute path back. Having a wallet is not the same as having a rail, because the rail includes what happens when something goes wrong.

The four layers, and the two that get skipped

The anatomy is a stack, and it is worth drawing because the layers get built out of order. At the top is the host shell: the account, the navigation, the search, the thing the user opens. Below it are the shared platform services: identity and consent, payments and refunds, notifications, support. Below that is the runtime: the sandbox mini apps execute in, the permission scopes they may request, and the review and release process that governs them. At the bottom is supply, which is the mini apps themselves, most of which you did not write.

The two middle layers are the ones that get skipped, and for an understandable reason: neither is visible in a demo. A product review of the host shell is a screen you can show. A product review of a permission scope model is a document. So the shell gets built, some services get bolted on above it, and the moment a partner asks to build inside, the team discovers that identity was implemented three times with three different notions of what verified means, and that there is no answer to who handles a refund when the partner took the money.

The permission scope model is the piece that decides whether any of this is safe. When you let another company ship code that runs inside your app next to a wallet, the questions are immediate: can it read the user name, can it see the phone number, can it start a payment, can it read a payment it did not start, can it stay resident, can it send a notification. Every one of those is a scope, every scope needs a review criterion, and the whole set has to be legible enough that a merchant developer can plan against it. Get it wrong in the permissive direction and one bad partner is a security incident with your logo on it. Get it wrong in the restrictive direction and nothing worth building can be built.

The layer people find most surprising is support. In a bundle, support is per feature and the team that wrote the screen answers for it. In a platform, the user does not know or care which company wrote the screen they are complaining about. They opened your app, they lost their money, they are calling you. So the host owns the complaint regardless of who caused it, and the settlement and dispute mechanics have to exist before the first partner rather than after the first incident.

What each layer owns, and what it must not own

Host shell

Owns

The account, the entry point, navigation and search, and the decision about which mini apps get shelf position

Must not own

Business logic for any individual service. The moment the shell knows about food delivery specifically, it has stopped being a shell

Failure signal

The home screen becomes a launcher with twelve icons and no opinion, because nothing is deciding what the user sees first

Shared platform services

Owns

One identity record, one consent record, one payment rail with settlement and refunds, one notification channel, one support path

Must not own

Service-specific rules. A refund policy belongs to a partner, the mechanism for executing a refund belongs here

Failure signal

Two services disagree about who the user is, or a refund requires a human to move money manually

Mini app runtime

Owns

The sandbox, the permission scope catalog, the SDK contract, and the review and release process

Must not own

Judgments about which businesses are worthwhile. That is a commercial decision, and mixing it into technical review makes both slower

Failure signal

Review takes weeks and merchants cannot predict the outcome, so the good partners stop applying

Third-party supply

Owns

The services themselves, their pricing, their inventory and their own product decisions

Must not own

The user relationship. If a partner can move the user off the host, the host is an advertising channel and will be priced like one

Failure signal

Most supply is written by the host company, which means the platform did not open, the org chart just reorganized

Two preconditions, and neither can be added later

Everything above is architecture, and architecture is the easy part. What decides the outcome is two properties of the app you already have, and they are properties rather than features, which is why they cannot be shipped.

The first is frequency. The host has to be opened out of habit, ideally daily, and by habit rather than by prompt. This is the multiplier on everything: a partner service placed inside an app opened once a month is a service opened less than once a month, because not every open reaches that shelf. Frequency is also the property least amenable to being added. You cannot make an app habitual by adding a reason to open it, because the added reason has to compete with whatever the user currently does instead, and that incumbent is usually a messenger or a bank app that already won.

The second is a working transaction. Money has to already move inside the app, with a settled trust relationship around it, before a shelf of partner services means anything. This precondition gets underestimated because a wallet looks like a feature. It is not: the transaction is a trust event, and the first time a user pays inside your app they are deciding whether this is a place where money is safe. If that answer is not already yes, partner services inherit a doubt they did nothing to earn and cannot fix.

Take the two together and they describe a position rather than a product: opened daily, already transactional. That position is the anchor, and the whole point of the anatomy in the previous section is to convert an anchor position into a platform. If you have the anchor, the architecture is a large but ordinary engineering program. If you do not, the architecture is beside the point, and the honest project is to earn one of the two properties first and revisit this in a year.

It is worth being precise about why the order cannot be reversed. Suppose you have frequency but no transaction, which is the position of a news app or a messenger. Adding a wallet is a real project but a possible one, because you have attention to spend on introducing it. Now suppose you have a transaction but no frequency, which is the position of an airline app or an insurance app. There is nothing to spend, because the user is not there to be told anything. That asymmetry is why frequency is the harder of the two to acquire and the one worth protecting most.

Testing the two preconditions against numbers you already have

• What share of monthly actives open the app on a given dayThe frequency question stated so your analytics can answer it today. Read it as a ratio rather than a target, and read it without counting the opens your own notifications caused.
• How many opens are prompt-driven rather than habitualSegment opens that followed a push from opens that did not. If the habitual share is small, the frequency is rented and it stops when the prompts stop.
• Whether money moves inside the app or only through itA link out to a payment page is not a rail. The test is whether you can execute a refund without a human moving money manually.
• What share of users have completed a payment at allA wallet used by a small fraction of actives is a feature, not a rail. Partner services attached to it reach that fraction, not your user base.
• Whether you would survive owning a partner mistakeThe host answers for the complaint. If one partner failure would be existential for trust in your brand, the platform is premature regardless of the other four answers.
• Who inside your company owns shelf positionIf nobody can say who decides what appears on the home screen, the platform has no editorial function and will become a launcher with twelve icons.

Four platforms, four starting positions, one destination

This is where the listicles mislead most, because a ranked list implies the entries are the same kind of thing arranged by quality. They are not. The instructive fact about the named platforms is that they started from four structurally different places, and the route each took is why its feature list means something different from an identical feature list somewhere else.

Take the messaging starting position, which is where WeChat began. Messaging gives the strongest possible frequency and no transaction at all. Opened constantly, all day, by habit, with an existing social graph, and not a single payment. So the work was to introduce a transaction into an app people already lived in, and the attention available to do that was abundant. What follows from that route is a platform whose mini apps are overwhelmingly discovered socially, because the underlying habit is social, and a runtime that had to become good very early because third-party supply arrived quickly.

Take the wallet starting position, which is where MoMo and ZaloPay began. A wallet gives you the transaction immediately and weaker frequency, because paying is not something most people do many times a day. The work here runs the other way: you have trust around money and you need reasons to be opened when nobody is paying. That is why wallet-origin platforms move toward bill payment, transfers between people and small recurring errands. Those are not arbitrary category choices. They are the categories that convert an occasional payment app into a daily one, which is the missing precondition being deliberately acquired.

Two wallets from the same market taking visibly different routes is the most useful comparison in this whole topic, and it is why the two Vietnamese wallet queries rank separately. Same country, same regulatory environment, same starting anatomy, different sequencing of which categories came first and how much supply was written in-house rather than opened to partners. Scoring those as a competition misses the point. Read as two routes, they show that the sequence is a genuine decision with consequences rather than a fixed playbook.

Then take the transactional-but-infrequent starting position, which is where AirAsia began, and which is the hardest route. An airline app has a real transaction, a verified identity, payment credentials on file, and a frequency problem that is structural rather than fixable by product work, because people do not fly weekly. Attempting a platform from there means buying frequency: acquiring or building categories that are opened often and attaching them to the identity and payment assets already in place. That is a legitimate strategy and a much more expensive one, because you are paying for the property the messaging route got for free.

The fourth position worth naming is the one most readers are actually in, which is none of the above. A retail app, a services app, an internal tool with a customer-facing edge: moderate frequency, a transaction that happens sometimes, no social graph. None of the three routes above starts there, and that absence is information. It does not mean the position is hopeless. It means the first project is not a platform.

The four starting positions and what each one has to buy

	Frequency at the start	Transaction at the start	What the route has to acquire
Messaging originWeChat	Very high, habitual, all day	None	A transaction, introduced into abundant existing attention
Wallet originMoMo, ZaloPay	Moderate, event-driven	Yes, with trust attached	Frequency, bought with errand-shaped categories
Travel or booking originAirAsia	Low, and structurally so	Yes, high value and infrequent	Frequency, which cannot be organic here, so it is acquired
Retail or services originmost readers	Moderate at best	Sometimes	Both, which is why the platform is not the first project

The feature list is downstream of the position. Two apps with identical features and different frequencies are not competitors, they are different businesses that happen to look alike in a screenshot.

Why open the platform at all, stated as arithmetic

There is a version of this decision that sounds like ambition and a version that is arithmetic. The arithmetic one is more persuasive to the people who have to fund it.

Every service you build yourself re-implements four things. It needs to know who the user is, it needs to take money, it needs to notify them, and it needs a support path when something goes wrong. Build two services and you have implemented those four twice, or if you were disciplined, once and shared it. Build eight and the discipline has usually failed somewhere, because the eighth service had a deadline and the shared identity layer did not quite fit its case.

Every service a partner builds inside your runtime consumes those four from you exactly once, because they are yours and the partner has no ability to reimplement them. The arithmetic is unglamorous: your integration cost scales with the number of services when you write them and stays flat when partners do. That is the entire financial argument for a platform, and it is why the shared services layer is the product rather than the plumbing.

The cost on the other side of the ledger is the review function, and it is a permanent operating cost rather than a project. Somebody has to check identity and business papers, test that requested permission scopes match what the mini app actually does, run a refund and a dispute end to end before launch, and audit again on every release. Skip it and the first bad partner is a security incident inside a payment app. Under-resource it and review becomes slow and unpredictable, at which point the good partners stop applying and you are left with the ones who had no alternative.

Weigh those honestly and a platform is worth it when you expect enough third-party supply that the flat integration cost beats the linear one, and when you can fund a review function indefinitely. Both are easier to judge before you start than after, which is the whole reason to state it as arithmetic rather than as a vision.

Four concerns every service needs Identity, payment, notification, support. Written once in a platform, re-implemented per service in a bundle.

Flat integration cost with partner supply A partner cannot reimplement your rail, so every new mini app consumes the same four exactly once.

Ongoing cost of the review function Not a launch project. Every partner release needs auditing, which makes review a standing team rather than a milestone.

How this fails, and the failure is rarely technical

The failures cluster, and almost none of them are engineering failures. The most common is the one already described: a bundle built in the belief that it is a platform, where all the supply is written in-house and the runtime is either absent or used by nobody outside the company. The tell is easy to check. Count the mini apps written by other companies. If the answer is close to zero after a year, the platform did not open, the org chart just reorganized.

The second is an empty runtime with a real sandbox, which is more painful because the engineering was done well. The permission model is sound, the SDK exists, review works, and no partner wants in. That is almost always a value problem rather than a technical one: a merchant compared building inside your app against buying an ad, and the ad won. The fix is not more documentation. It is more users, better shelf position, or a cheaper path to a paying customer, and all three are commercial decisions.

The third is the shelf position problem, and it appears exactly when things are going well. Supply arrives, the home screen has finite room, and every partner wants the top of it. Now you are an editor and a market maker whether you planned to be or not. Companies that had not decided who owns that call end up either auctioning position to the highest bidder, which degrades the user experience that made the position valuable in the first place, or freezing it, which tells good partners their effort will never be rewarded.

The fourth is the support and dispute failure, and it damages the host most. A user pays inside your app for something a partner sells, it goes wrong, and they call you. If the settlement mechanics do not let you refund without a negotiation, and if no single owner exists for the complaint, the user learns that money is not safe in your app. That lesson generalizes instantly to every other service inside it, including the ones you wrote, which is how a single partner failure damages the whole host.

The fifth is quieter and worth naming because it is a measurement error. Teams track installs of mini apps and screens shipped, both of which go up regardless. The numbers that matter are whether daily opens of the host went up and whether repeat transactions per user went up. A platform that added forty mini apps and moved neither is a larger app, not a better position.

What to do when the runtime is built and nobody is building in it

Is the problem that partners cannot build, or that building is not worth it to them?

• Partners applied and gave up during review

  Fix predictability before anything else

  Unpredictable review is worse than slow review. Publish the criteria, publish the expected duration, and let a developer plan against it. Merchants abandon uncertainty faster than they abandon effort.

• Partners looked and never applied

  This is a value problem, not a platform problem

  Compare what you offer against what an ad costs them per acquired customer. If your users are too few or shelf position too weak, no amount of SDK work changes their answer.

• Partners built, launched and churned out

  Look at settlement and support, not the runtime

  Partners leave when getting paid is painful or when they carry complaints caused by your rail. Both are operational, and both are invisible in engineering metrics.

If you have the anchor, what the first year actually contains

Suppose the preconditions hold: opened daily, already transactional, with a funded review function and a named owner for shelf position. The first year is then a large but ordinary engineering program, and it is worth knowing its shape because the sequence is not obvious.

The first block of work is consolidation, and it is unglamorous. One identity record, one consent record, one payment rail with settlement and refunds, one notification channel. If your app has grown features over several years, this is mostly a migration, and the consent piece is the part that surprises teams: users consented to different things at different times under different wordings, and a single record has to be honest about that rather than assuming the most permissive version.

The second block is the runtime and the scope catalog. This is where the decisions with the longest half-life get made, because a permission scope you publish is a contract you cannot quietly change once partners depend on it. Publishing fewer scopes than you think you need is the safer error. Adding a scope later is routine, and narrowing one later breaks live partners.

The third block is the review function as an operating capability rather than a checklist: who checks papers, who tests scopes against actual behavior, who runs a refund and a dispute end to end before a partner goes live, and what the published timeline is. Building this before the first partner rather than during is what makes the first partner experience good, and your first few partners are also the reference customers for every partner after them.

The fourth block is the one teams want to do first and should do last, which is supply. Recruit narrow: a small number of categories that fit the habit the host already has, with partners who can survive a real review. Wide early recruitment produces a launcher and a support queue. Then measure the two numbers that matter, daily opens and repeat transactions, and let those decide the next categories instead of letting the roadmap decide them.

One note on the arrangement rather than the architecture, since it is where the timeline usually slips. This program touches payments, consent and third-party code review at the same time, which means it needs a team that stays. A rotating set of contractors will build the shell and leave the scope catalog half-decided, and half-decided scopes are the expensive kind. If you are resourcing this with outside help, the shape that fits is a standing team you direct rather than a fixed scope handover. That distinction is the whole subject of the offshore development center guide, and it is worth reading properly if you have not made the choice before, because the two arrangements respond very differently to a scope catalog that is still moving. How to verify the partner behind that team before signing is the subject of our guide to evaluating a software development partner, and the location trade underneath every such arrangement is worked through in onshore, nearshore and offshore compared.

The four blocks, and what tells you a block is genuinely finished

1. Consolidate the shared servicesFirst, and longer than estimated

   One identity, one consent record, one payment rail with refunds and settlement, one notification channel

   Done when A refund can be executed end to end without a human moving money, and no two services disagree about who the user is

2. Runtime and scope catalogOverlaps the first block late

   The sandbox, the published permission scopes, the SDK contract and its versioning policy

   Done when An outside developer can read the scope catalog and predict what review will say about their app

3. Review as an operating functionBefore the first partner, not during

   Named owners for papers, scope testing, refund and dispute rehearsal, and a published timeline

   Done when A dry run with a friendly partner completes inside the published timeline with no improvised decisions

4. Recruit narrow supplyLast, then continuously

   A few categories that fit the existing habit, with partners who can pass review and survive settlement

   Done when Daily opens of the host and repeat transactions per user both moved, not just mini app installs

The scope catalog decisions worth making deliberately

1. 1

   Separate reading identity from reading contact detailsCheap now, impossible to split later

   A mini app usually needs to know the user is verified, not what their phone number is. Splitting these two is the highest-value scope decision available, because it lets most partners operate without touching the data that raises the stakes of any mistake.

2. 2

   Make initiating a payment distinct from reading payment historyThe one your reviewers will thank you for

   Almost every partner needs the first. Almost none need the second. Bundling them is the classic over-permissive default, and it makes every partner a data risk in proportion to your entire payment history rather than their own transactions.

3. 3

   Treat notification access as scarce and revocableProtects the precondition

   Notifications are the host habit, and habit is the asset. A partner that can notify freely can burn the frequency that makes the platform worth anything, so this scope needs rate limits and a revocation path that does not require a release.

4. 4

   Version the contract from the first published scopeDo it before it matters

   You will need to change this. Deciding the deprecation policy while you have zero partners costs a meeting. Deciding it with two hundred partners costs a quarter and some goodwill.

The honest test: most companies should not build one

Here is the part the ranked lists leave out. The super app is a position, positions are scarce, and in most markets the ones worth having are already taken by whatever people open every day. If your app is not that, the platform strategy is a way of not asking why.

The test is short. Do people open your app on most days, by habit, without a notification prompting them? Does money already move inside it, in a way you could refund without a human intervening? If both answers are yes, the rest of this article is your program. If frequency is yes and the transaction is missing, the honest project is introducing a transaction into attention you already have, which is a real project with a good chance of working. If the transaction is yes and frequency is missing, you are in the hardest position, and the question is whether you can attach to something opened daily rather than trying to become it.

If both are missing, the useful conclusion is that the super app conversation is premature and slightly dangerous, because it offers a large exciting project in place of a small uncomfortable question. The small question is why the app you already have is not opened, and it has a much better return.

None of this makes the anatomy wasted knowledge if you decide against a platform. The four layers are good architecture for any app that expects to add categories over time, and consolidating identity, payment, notification and support pays for itself well before any partner exists. Build the middle two layers because they make your own services cheaper, and treat opening them to third parties as a separate decision you can take later from a much better position.

If you are somewhere in the middle, which is common, the reasonable move is to sequence rather than commit. Consolidate the shared services, because that is valuable either way. Keep the runtime as a design rather than a build. Revisit the two preconditions in a year with real numbers. That path costs very little and keeps the option open, which is worth more than a platform announcement.

What to do from each of the four positions

Your position	The reasonable next project	What to explicitly not do yet
Daily opens and a working transaction	Consolidate shared services, then the runtime, then narrow supply	Recruit supply widely before review is a real function
Daily opens, no transaction	Introduce a transaction into the attention you already have	Open a runtime, because partners would inherit a trust question you have not answered
A transaction, not opened often	Attach to something opened daily, or build depth instead of breadth	Assume new categories will create frequency on their own
Neither	Find out why the app you have is not opened	Treat the platform as the answer to a question you have not asked yet

Read your own row rather than the aspirational one. Three of these four rows do not begin with building a platform, which is the point.

Frequently asked questions

If you want the two preconditions checked against your own analytics before anyone scopes a platform, we are a software development company in Vietnam that will tell you plainly when consolidating what you already have is the better project.