Why super app architecture breaks on the second release
The first version of a super app comes together quickly: a single repository, shared modules for authorization, payments, and profile, and one data layer. While there are two or three teams, this speeds up work — logic and screens do not need to be duplicated.
The problem shows up on the second release, when there are more modules and each one follows its own schedule.
By this point, the shared code and data have grown, and any change in a core module affects neighboring ones. Coupling between application modules grows implicitly — through shared models, cache, navigation, and environment settings.
Builds stop being predictable: a change in one section breaks another, and verification requires running scenarios for the entire product.
A single point of failure emerges. The shared layer — session state, configuration, a shared screen — takes down not an individual scenario but the entire application, including sections the change did not touch.
An error in a shared module affects all users at once, and localizing it from logs becomes difficult.
Release time grows: instead of isolated delivery of one module, the team coordinates dates with everyone who touches shared code.
A release turns into negotiations and synchronized verification, and an urgent fix requires a full rebuild and re-running all checks — including those unrelated to the change.
This is not a consequence of a weak team but a result of how boundaries between product areas are drawn. Below we break down how this is addressed: contracts between modules, independent builds, failure isolation, and each area having its own data.
What a modular core provides: releases, fault tolerance, load
A modular core separates the screen, domain logic, and integrations into independent modules with an explicit contract. The contract describes what a module exposes externally and prohibits accessing a neighbor's internals directly.
The core remains thin: navigation, dependency graph, shared design layer — everything else is connected as a separate build.
Independent module releases change the release cycle itself. A team builds and ships its part without waiting for others: the full test run is reduced to checks of the changed module and its contracts, and the shared build stops being a blocking point.
Modules on different stacks coexist — some cross-platform blocks are conveniently built with Flutter, while heavy areas remain native.
Application fault tolerance relies on failure isolation. A payment module crash does not take down the catalog and feed: the core intercepts the error, marks the module as unavailable, and shows a degraded scenario instead of closing the application.
Crash analytics is tracked by module, so it is clear what share of crashes is localized within one block, and a fix does not require rebuilding the entire product.
Scaling under load is a consequence of the same boundary. Heavy scenarios (feed, search, recommendations) move into separate services and grow by their own metric, independently of the rest.
The application loads modules on demand, so cold start time does not increase with the number of features, and at peak load a specific service fails: the remaining sections continue to work from cache and local data.
Application composition approaches: monolith, modular monolith, services
The choice of composition depends not on trendiness but on how many teams work on the product and how independently they need to release changes. While there are five modules and one team, splitting into services brings more interaction overhead than benefit.
When there are three or four areas and each has its own release rhythm, release speed starts to be determined precisely by module boundaries.
In practice, platforms go from a single application to a modular monolith, and extract individual nodes into dedicated services — payments, notifications, search. Below are the applicability and limitations of each option.
| Option | When it fits | Limitations |
|---|---|---|
| Single application | One product, one team, a short list of scenarios, demand validation stage | Shared build: a change in one screen pulls the entire release, build time grows, and intersections between areas grow |
| Modular monolith | Several teams and areas in one product, independent releases are needed without operating a distributed system | Discipline is required: module boundaries are set by build rules; otherwise, links grow through and the module loses autonomy |
| Dedicated services | Nodes with separate load, their own pace of change, and fault-tolerance requirements: payments, notifications, catalog | Exchange latency, distributed transactions, separate monitoring, and versioning of contracts between nodes |
| Hybrid | Some nodes have matured enough for autonomy, while the core is still changed collectively | Clear contracts and regulations are needed; otherwise, state diverges between the core and services |
We fix the set of modules and where their boundaries run before development starts: this determines repository structure, build scheme, and release order.
Platform design stages: from schema to handover
We start platform design with an inventory: which services already operate, what we reuse, where authorization, payments, and notifications are duplicated.
The output of this stage is an agreed module schema and contracts between modules; without them, a super app turns into a set of applications under one icon.
- Current-state assessment. A map of screens, services, and integration points, bottlenecks, and dependencies that block independent releases.
- Module schema. Boundaries: shell core, shared services, domain modules. The criterion is that a module builds, verifies, and releases without touching the others.
- Contracts between modules. Exchange formats, versioning, behavior when a neighbor is unavailable. An updated module must not break an already released version of the application.
- Environments and builds. We separate development, pre-release verification, and release environments, move settings out of code, and set up automated builds with a shared release order.
- Architecture verification. Module failure scenarios, updates without stopping the application, load growth; we test on real devices and weak networks.
- Handover to the team. We provide schemas, documentation, regulations for adding a new module, and conduct training — so the customer's team can evolve the platform.
Module schemas, service contracts, and release regulations
Super App architecture lives longer than the team that built it — but only if decisions are fixed in artifacts rather than in chat.
Platform handover follows an acceptance checklist: the customer receives a package that can be used to evolve the product in-house or hand it to another team without reverse engineering. What it includes is below.
- Module map — the area of responsibility of each module, its dependencies, and extension points. It shows what changes in isolation and what will pull neighbors along.
- Data exchange description — contracts between services, message formats, versioning rules, and behavior when a neighbor is unavailable: retries, queue, degradation mode.
- Access rules — roles and scopes, permission check points, issuance, renewal, and revocation of keys between modules and external systems.
- Release regulations — branching, mandatory automated checks, rollout stages, rollback criteria, and incident response procedure.
- Platform documentation — environment schema, application build and signing, list of external integrations, and boundaries of responsibility between parties.
- Architecture decision log — which options were considered, what was chosen and why, including reasons for rejecting alternatives. Reconstructing this from memory is the most expensive.
- New module connection scenario — step by step: which contracts to describe, where to register, which checks to pass before rollout.
The package lives together with the product: a change to a contract or release regulations goes as one change with the document. During acceptance, we verify this in practice — open the map for any module and compare it with how it is built.
Case study: how the application withstood growth and accelerated releases
The starting point was a monolith: one build, a shared release pipeline for all teams, and a single “release” button.
As the user base grew severalfold, this became a bottleneck — a change to one screen waited for a shared release, and a failure in one domain (payments, delivery, support) led to rolling back the entire client. Recovery time reached six hours because the whole build had to be rebuilt and verified in full.
What was changed
Domains were moved into independent modules with versioned contracts, while navigation, authorization, and analytics remained in the shared layer. Each team received its own pipeline: module build, contract checks, phased rollout to a share of the audience, and fast rollback.
The server side was split into services and launched in Kubernetes — a rollback affects one service and its contract, not the entire platform.
What changed
Releases by team accelerated: instead of waiting for a shared date — a few days from code readiness to the audience, and some changes arrive via remote configuration without an application update at all. Recovery time after a failure dropped from hours to minutes.
The price of independence is the shared layer: changes to navigation and authorization go through separate review; otherwise, modules start pulling each other again.
How a modular super app differs from a set of separate applications
A modular super app is a single container application that hosts independent modules: storefront, orders, payments, delivery, account.
The container handles navigation, single sign-on, the shared design layer, and update mechanics, while each module is built, tested, and versioned separately. The user installs one application and gets all services with one profile, one cart, and one transaction history.
A set of separate applications is structured differently: each product carries its own authorization, its own payment flow, its own notifications, analytics, and support screen.
In a typical landscape, 60-70% of code is duplicated across codebases, and a change in security rules or the payment scheme is repeated as many times as there are applications in the portfolio. Then shared library versions diverge — and teams begin breaking compatibility for each other.
The cost shows up in releases. The container allows service changes to be released within it without re-running the full review cycle in App Store, whereas each build from the set goes through its own approval.
A shared platform provides what cannot be assembled piecemeal: end-to-end analytics across all services, a single session, shared search, and recommendations.
A new section is launched as a module within one release cycle, rather than as a separate product with its own store listing and its own support.
The flip side of modularity is discipline requirements. Strict contracts between modules, interface versioning, and failure isolation are needed: without this, a crash in one section takes down the entire container.
Even at the start, we fix which parts live in the shared platform and which remain autonomous — otherwise, a modular super app degenerates into the same disparate applications, only inside one window.
Technical concerns before starting: integrations, data, support
Concerns before starting usually relate not to the super app itself but to the seams around it: how it connects to systems that are already running, what happens to accumulated data, and who is responsible for the platform after launch.
Below are the four most frequently asked questions and how we answer them at the architecture level.
How will the super app integrate with current systems?
We do not rewrite working systems; instead, we place an adapter layer between them and the platform: each integration gets idempotent calls, retries with increasing delay, and explicit degradation.
If an external service is unavailable, the module returns the latest correct data instead of an error on the screen.
How is data migrated without downtime?
The approach is a snapshot plus change catch-up from the log, then reconciliation for each entity: record count, checksums, referential integrity. We switch after a shadow run on real traffic, with a rollback point to the source system.
What about access rights and accounts?
A unified role and attribute model, single sign-on with the existing user directory, and permission checks at the service level rather than the interface level. Actions with sensitive data go into the audit log, and modules receive the minimum necessary scope of access.
What is included in platform support after launch?
Modules are updated independently, so a release of one section does not pull the others along. We set up metrics and alerts for critical paths, version release regulations, and updates to meet app store requirements and current operating system versions.
Let's discuss the task and come back with an estimate and work plan
The more specific the input data, the fewer assumptions in the estimate.
Therefore, for the conversation it is useful to collect not design wishes but the actual state of the product: which services already exist inside, how they authorize the user, and where they store their data. Then we turn this into a module map and core boundaries.
- A list of service modules that must live in one application, and what remains separate products.
- The current authorization and unified profile scheme: where tokens are issued, how account logout is organized, and whether an end-to-end session between services already exists.
- The payment flow and work with external providers: who initiates a payment, where transaction history is stored, and which checks are mandatory.
- Load and offline mode requirements: which screens must open from local cache and which may be loaded on demand.
- Access to app store accounts, build servers, and analytics systems — arranging these often takes longer than the first development stage.
- Constraints: platform rules, external requirements for personal data storage, and operating system versions that must be supported at launch.
After discussing the task, we come back with an estimate and work plan: team composition for the specific scope — architect, platform module engineers, mobile developers, build and release specialist — a breakdown by stages, integration points, and preparation order for the start.
Describe the task in free form and attach what you already have from the list above — that is enough to begin a substantive conversation.