Shell-and-modules architecture
Also: host and mini-app architecture, modular app architecture
What is Shell-and-modules architecture?
Shell-and-modules architecture splits a large app into a host shell that owns identity, payments, navigation and shared services, and independent modules that each deliver one service and can be built and released separately.
What Shell-and-modules architecture means
The shell is the part of the app every module depends on: authentication and session, the wallet or payment layer, the navigation frame, push notification routing, analytics, design system components and shared APIs such as location and contacts. Modules are self-contained feature areas (delivery, bookings, support) with their own screens, state, backend services and team. They talk to the shell through a defined contract and never to each other directly.
Modules can be compiled into the app, loaded dynamically as bundles, or delivered as mini-apps in a sandbox with restricted access to shell capabilities. The choice trades startup performance and app size against independent release cadence and third-party participation. Whichever mechanism, the shell must enforce boundaries: a module gets a scoped token, a versioned API and a limited set of shell services, not the run of the whole app.
This is the architecture behind every super app, but it applies to any large product built by several teams. It is not the same as microservices on the backend, though the two often go together, and it is not a monorepo decision; it is about runtime boundaries and ownership.
Who it really matters to
- CTO / Head of Engineering: module boundaries decide whether ten teams can ship into one app without blocking each other.
- Product manager: a stable shell contract means a new service can be launched as a module in weeks rather than through a full app release.
- CISO: modules, especially third-party ones, must run with scoped permissions so a flaw in one cannot reach payments or identity.
- Operations head: independent module releases mean a fix in one service does not wait for every other team's release train.
Why it exists
The pattern exists because one large app built by many teams becomes impossible to change: every release blocks on every team and any bug can reach any feature. A shell with strict module contracts lets teams work independently, keeps sensitive capabilities in one audited place and lets new services launch without touching the core. The trade-off is upfront design of the shell and ongoing governance of the contract; a weak shell leads to modules bypassing it, which quietly recreates the monolith.
Where it is applied
- A payments super app where bill pay, insurance and lending modules share one wallet and login.
- A retail app whose store, loyalty and support modules are owned by different teams with separate release schedules.
- A logistics platform app that lets partner services ship mini-apps for insurance or packaging inside the shipper's app.
- A hospital group app combining scheduling, records and pharmacy modules under one patient identity and consent layer.
- A field operations app where each business unit contributes its own workflow module to a shared shell.
Is Shell-and-modules architecture a skill?
Technique / practiceAn architectural pattern implemented with mobile frameworks and module loading mechanisms, not an off-the-shelf product. Eazyware's super app development and React Native mobile services design the shell, define the module contract and build the first modules.
Eazyware service that covers it: Super App Development. Starting prices are on the pricing page.
Frequently asked questions
What belongs in the shell and what belongs in a module?
Anything every service needs and anything security-sensitive belongs in the shell: identity, payments, notifications, analytics, design system. Anything specific to one service belongs in its module. If two modules need to share something, promote it to the shell rather than linking them.
Do modules need separate backends?
Usually each module has its own backend services owned by its team, with the shell exposing shared APIs for identity and payments. This keeps ownership clear, though a small company can start with one backend and split it as teams grow.