Super app architecture: shell, modules and shared services
What does a good super app architecture look like?
A shell app owns identity, wallet and navigation; verticals are independent modules on a shared microservices backend. The shell stays small, each module ships on its own schedule through a versioned contract, and identity, payments, notifications and orders are backend services every module uses, not rebuilds.
Super app architecture comes down to three layers with strict boundaries: a shell that owns identity, wallet, navigation and the module lifecycle; modules that each deliver one vertical and can be built, released and removed independently; and a shared backend of services that every module calls rather than reimplements. Get the boundaries right and ten teams can ship into one app without blocking each other. Get them wrong and you have a monolith with a wide home screen that slows every release. This article describes the layering we use in super app development, the contract between shell and module, the shared services that belong on the backend, and the release process that keeps the whole thing stable.
Why the three-layer split matters
A super app is several businesses in one binary. Each business has its own team, roadmap and failure modes. If they share code freely, one team's bug blocks another team's release, and the app store review cycle becomes a queue everyone waits in. The three-layer split turns the app into a platform: the shell changes rarely, modules change often, and the backend evolves through versioned APIs. The organisational shape follows the technical one, which is the main reason the split is worth the discipline.
The shell: small, stable, owned by one team
The shell is the native application users install. It owns login and session, the wallet and stored payment methods, the home screen and navigation, push notification routing, deep links, the module registry, feature flags, crash reporting and the update mechanism for modules. It does not know what a restaurant or a bus ticket is.
Its job is to be boring. It should have a small surface, a high test coverage and a release cadence measured in months. Every capability the shell exposes to modules is versioned, and modules declare the shell version they need, so an old module keeps working on a new shell.
Modules: how a vertical gets in
| Module approach | How it is built | Best for | Trade-off |
|---|---|---|---|
| Native module in the same binary | Separate package per vertical, compiled into the shell | First-party modules with deep native needs such as maps or camera | Every change needs an app store release |
| Bundled JavaScript or React Native module | Vertical ships as a bundle the shell loads, updatable over the air | Most first-party modules; frequent releases | Native features go through a bridge the shell must provide |
| Web mini app in a controlled web view | Vertical is a web app with a JavaScript bridge to shell capabilities | Partner modules; fastest to onboard | Performance and feel are lower; bridge security must be strict |
| Hybrid per module | Choose per vertical from the three above | Mature super apps with mixed first-party and partner catalogue | Two or three toolchains to maintain |
Most Indian super apps we see use a React Native shell with over-the-air bundles for first-party modules and a web-view path for partners. The React Native documentation is the primary reference for the runtime; the module contract is what you design on top of it.
The shell-module contract
The contract is a versioned interface the shell exposes to every module: who is the user, what tokens they hold, how to pay, how to send a notification, how to navigate to another module, how to report an event, and what device capabilities are available. Modules get a scoped token, never the root session, and each capability is permissioned in the registry so a partner module cannot read the wallet balance unless explicitly allowed. Treat the contract like a public API, with the same versioning discipline as API-first SaaS.
Isolation between modules
Modules do not import each other. If food delivery needs the user's address, it asks the shell's profile service, not the transport module. Module storage is namespaced, module crashes are contained by the shell, and a module can be disabled remotely through the registry without a release. This is what makes it safe to open the platform to partners later.
The super app backend: shared services
The backend is where the real leverage is. A set of shared services, each with its own team, data store and versioned API, serves every module. The minimum set: identity and KYC, wallet and payments, notifications, profile and addresses, catalogue and search, orders, support and disputes, and an event bus. Modules add their own vertical services, such as dispatch for delivery or inventory for a store, and call the shared services for everything else.
Shared services must be multi-vertical by design. An order in the orders service has a vertical type and a payload the vertical owns; the service handles lifecycle, payment linkage and refunds identically for a cab and a meal. The wallet service settles both against the same ledger. Notifications route through one preference model. This is the difference between a super app and a set of apps that share a login.
The event bus
Every shared service publishes events: order created, payment settled, delivery completed, ticket opened. Modules and analytics subscribe. The bus is what lets personalisation see the whole customer and lets a support agent see the whole history. It is also what the AI layer consumes, as described in event pipelines: the foundation of personalisation.
Release process across teams
The shell releases on a slow cadence through the app stores. Modules release over the air on their own schedules, gated by the registry: a new bundle is published to a percentage of users, watched for crash and conversion metrics, then promoted or rolled back without touching the shell. Feature flags live in the shell and are readable by modules, so a vertical can dark-launch a feature and turn it on by cohort. Contract changes to the shell are announced with a deprecation window, and modules declare compatibility, so nothing breaks silently.
Where AI fits the architecture
A conversational entry point in the shell can route a request to the right module, using the same contract and scoped permissions a module gets. Personalisation on the home screen draws on the event bus. Support agents, human or AI, operate on the shared orders and support services and therefore see every vertical. None of this needs to be built into modules; it sits at the shell and backend layers, which is why it is cheap to add once the architecture exists. The multilingual voice agent for a hospital network case study shows a shared entry point routing across several departments, which is the same problem shape.
A worked example
A payments company with a wallet app wanted to add bill payments, transport tickets and a partner-run food vertical. Its first attempt built everything into the wallet codebase; within a year the ticketing team could not release without the payments team's sign-off, and a partner integration had crashed the app for everyone.
The rebuild extracted a shell owning login, wallet and navigation, with a versioned contract and a module registry. Bill payments and transport became over-the-air React Native modules owned by their own teams. The partner food vertical moved into a controlled web view with a bridge that exposed only pay and notify. The backend was reorganised around shared identity, wallet, orders and notification services with an event bus, and each vertical kept its own service for the parts only it understood. The shell's release cadence dropped to quarterly while modules shipped weekly, and a misbehaving partner module could be disabled remotely in minutes.
Team and timeline
The shell and shared services are a platform team: a mobile lead, two mobile engineers, a backend lead, three backend engineers, a DevOps engineer and a QA engineer. Each module is a separate small team working to the contract. Your side owns the product decisions per vertical and names a platform owner who arbitrates contract changes.
A shell with two first-party modules and the minimum shared services is a super app development engagement from $63,000 (₹41.6L), typically twelve to twenty weeks. Additional modules are scoped as React Native mobile work from $17,500 (₹11.2L) each, and new shared services as product and platform development from $42,000 (₹28L). A Sprint Zero at $3,250 (₹2,00,000) produces the layer boundaries, the contract and the service map before any code, and is credited to the build. The platform is run under an Enterprise Care Plan at $5,250 (₹3,40,000) a month; details are on the pricing page.
Before you start: a checklist
- Write down what the shell owns and what it will never know about
- Choose the module approach per vertical: native, over-the-air bundle or web view
- Draft the shell-module contract and its permission model before the first module
- List the shared backend services and which team owns each
- Decide the event catalogue every service publishes
- Set the release rules: shell cadence, module rollout percentages, rollback
- Agree how modules declare shell compatibility and how deprecations are announced
- Plan the registry so any module can be disabled remotely without a release
Glossary
- Shell: the installed app that owns identity, wallet, navigation and the module lifecycle
- Module / mini app: one vertical packaged to run inside the shell through a defined contract
- Module registry: the backend record of which modules exist, their versions, permissions and rollout state
- Shell-module contract: the versioned interface modules use to reach shell capabilities
- Shared services: backend services such as identity, wallet, orders and notifications used by every vertical
- Over-the-air update: shipping a new module bundle without an app store release
Related reading
Continue with what is a super app and should you build one, wallets, UPI and payments in super apps, and the dispatch platform case study for a vertical backend built to this pattern.
Keep the shell small, the contract versioned and the backend shared; everything else in a super app follows from those three rules.
Frequently asked questions
Should super app modules be native or web views?
▾
First-party modules are usually over-the-air React Native bundles for speed of release with native feel. Partner modules often start as controlled web views with a strict bridge. Deep native needs such as maps or camera justify a native module.
What is the minimum set of shared services in a super app backend?
▾
Identity and KYC, wallet and payments, notifications, profile and addresses, catalogue and search, orders, support and disputes, and an event bus. Each vertical adds its own services for what only it understands.
How do multiple teams release into one super app without conflicts?
▾
The shell releases slowly through app stores; modules release over the air on their own schedules, gated by a registry with percentage rollouts and remote disable. A versioned contract with declared compatibility prevents silent breakage.