What are super apps and should you build one?

A founder came to us with a colour-coded spreadsheet. It was meticulous, genuinely impressive to look at, and it mapped out roughly a dozen competitor products across the football industry. The plan was to merge them all into one. One app, everything covered, nothing left out. The founder was visibly pleased with themselves, and understandably so. The spreadsheet alone represented weeks of thinking.

The colour-coded spreadsheet was impressive, but it mapped competitor features, not user needs.

We started asking questions. Why would someone choose an all-in-one product over a specialised app that does one thing exceptionally well? Would consolidating those features risk making each of them noticeably worse? Who exactly was going to open this app, and what would they be trying to do in the first ten seconds? The founder became deflated. The questions were not hostile, but they were honest, and honesty is what the situation needed. Building on a founder's excitement rather than on user evidence serves nobody well, least of all the founder.

That conversation is not unusual. The appeal of the super app is real, and the thinking behind it is often genuine. But the distance between a compelling idea and a product people actually use is wider than a spreadsheet can show. This article works through where that gap comes from, what it costs, and how to think about scope before you commit to building it.

What a super app actually is

The term comes from Asia, where apps like WeChat, Grab, and Gojek built ecosystems that handle messaging, payments, food delivery, transport, and shopping inside a single product. The idea is that instead of switching between five apps, a user stays inside one. The product becomes a platform rather than a tool.

In Western markets, the term gets used more loosely. Founders sometimes apply it to any app that combines two or more functions, even if those functions are relatively modest. A fitness app with a meal planner and a community forum gets called a super app. A hospitality booking platform with integrated loyalty points and a concierge feature gets the same label. The word travels far from its origins.

The distinction matters because the original super apps succeeded in specific conditions. They grew in markets where smartphone adoption outpaced desktop infrastructure, where a single trusted brand could fill multiple gaps at once, and where network effects compounded across services. Those conditions are not automatically present in a skincare brand's app or a boutique fitness product. Calling something a super app does not mean it benefits from the same dynamics.

A more useful question than "is this a super app?" is "does combining these functions serve the user, or does it serve the product roadmap?" Those are different questions, and the answer shapes everything that follows.

Why the super app idea is so appealing to founders

The logic is understandable. If your users need three things, and you give them all three, you become more useful than a product that gives them one. They spend more time in your app. They have fewer reasons to leave. You capture more of their behaviour, which means more data, more revenue opportunities, and a stronger network effect over time.

There is also a competitive argument that sounds compelling. If you match everything your competitors do, and then add more, you win. The colour-coded spreadsheet is an expression of this thinking: find every feature in the market, combine them, and you have the best product in the market. It is tidy logic, and it is wrong often enough to be worth examining carefully.

Founders also find scope expansion emotionally satisfying in a way that focus is not. Adding a feature feels like progress. Deciding not to add one feels like giving something up. That asymmetry is hard to push against, especially when you are close to the product and convinced of its potential. According to Statista, 66% of global customers say they prefer super apps, which founders cite readily. What that figure does not tell you is whether those customers are expressing a preference for convenience in principle or a preference for your specific combination of features in practice.

The appeal of the super app is usually a good instinct pointing at the wrong solution.

How scope creep disguises itself as strategy

Scope creep rarely announces itself. It arrives dressed as opportunity. A feature that was out of scope becomes "obviously related." A function from a competitor's product looks like something users will expect. A second use case starts to feel like a natural extension of the first. Each individual decision seems reasonable. The aggregate effect is a product that has grown past what anyone originally agreed to build.

We worked on a grassroots football club app where two co-founders were deeply embedded in the world the product was designed for. Both were strong-willed and both consistently pushed to add more features, each convinced their additions were implied by the original brief. Because the app was the business itself, not a supporting marketing tool, both founders were professionally and emotionally close to every decision. Holding scope in that environment was genuinely hard. Each new feature had an internal advocate with real conviction behind it.

Each new feature had a passionate internal advocate, and scope grew until the product could no longer move.

The difference between scope creep and a genuine strategic decision is usually visible in the process. A genuine strategic decision comes with a conversation about what it replaces, what it costs, and what it delays. Scope creep skips that conversation. It presents the new thing as additive rather than as a trade-off, because trade-offs are uncomfortable and additions are easy to agree to in a meeting.

Before adding any feature to a product in development, ask what it displaces. If the answer is "nothing", treat that as a warning sign rather than a green light.

What happens when you build before validating the core

The grassroots football product we worked on was built on what the founders believed the product should do, rather than on what research was showing. We advised against overcomplicating it. We pushed for a simpler scope, a focused initial release, and room to iterate based on real user behaviour. The advice did not take hold. The product kept growing. Development eventually had to stop, and we ceased working with the team.

More than a year later, the product still had no marketable release. The public record was a series of "coming soon" announcements, each shifting the date forward. The founders had invested heavily in build, but because they had not validated the core before expanding the scope, the product never reached the people it was designed for.

We saw the same pattern on a fitness and wellness app where the founder's strong personal conviction shaped every decision. Research findings, focus group responses, and survey data were acknowledged and then set aside. The product became what we would call a vanity product: shaped by the founder's preferences rather than user evidence. Early signs included a persistent drive to perfect features before launch and repeated requests to roll back sign-offs already given. That project also exhausted its budget in design and build without reaching a fully live version.

Validation is not a phase you can skip to gain time. Skipping it moves the cost forward, not away.

Why combining features rarely adds up to a better product

On the grassroots football app, the client compared each individual feature in their product to the best-in-class single-purpose app that did only that one thing. The booking process needed to be as intuitive as a dedicated booking app. The community features needed to match a dedicated social product. The scheduling tool needed to rival a dedicated scheduling product. Each comparison was reasonable in isolation. Together, they described an impossible brief.

We pushed back. We ultimately complied with specific requests to iterate on parts of the experience. The changes made little measurable difference. The real problem was not how any individual feature worked. It was that the client was trying to do too many things inside one product, and there was a reason those features existed across several separate apps to begin with. Despite genuine effort to build something cohesive and emotionally grounded, the result was overly complex, too verbose, and wrong for its audience and core purpose.

Feature combination creates a hidden cost that does not show up in a roadmap. Every added function increases cognitive load for the user. It also increases the surface area for things to go wrong, the design effort needed to maintain visual coherence, and the time required to test and iterate. According to Futuristic Bug, nearly 60% of app features are rarely or never used, which means the resources behind them produced no meaningful return. The cost of building the wrong features is time and focus that the right features never received.

List your planned features in two columns: features that directly serve the primary user job, and features that serve secondary or aspirational jobs. Build the first column before the second column exists as anything other than a future consideration.

The cost of not launching

The most visible cost of an over-scoped product is time. But the less visible cost is what that time represents. A product sitting in development is a product accumulating debt: design decisions made without user feedback, assumptions hardening into architecture, and a window of market opportunity that may or may not still be open when the product finally emerges.

The grassroots football client refused to follow our advice to launch a limited feature set first and iterate. The scope kept expanding. The budget kept rising. The product never launched. We tried to get the client to focus on releasing a couple of things first, test the market, and grow from there. The client would not act on the advice. The product just kept growing, growing more complex than it needed to be, until the complexity itself became the reason it could not ship.

There is also a team cost that is easy to underestimate. Prolonged development without a launch date erodes morale. Decision fatigue sets in. The product gets revised in ways that undo earlier good decisions, because the team has been inside it so long that they can no longer see it clearly. Launching a focused product early is how you get the external signal you need to build something people will actually return to.

• User feedback gathered after launch is more reliable than assumptions made before it
• A focused product shipped is more useful than a complete product not shipped
• Budget spent on launch beats budget spent on features that delay it
• Market windows close while products are still in development

When a broader scope is genuinely justified

There are situations where a broader product scope is the right answer, and it is worth being precise about what those situations look like. A wider scope is justified when the functions being combined genuinely depend on each other to deliver value, when users would face a meaningful loss if forced to switch between separate tools to complete a single task, and when the product has validated a core before expanding around it.

We worked with a property developer building a concierge app for high-rise properties. They came to us with a pre-formed idea of what it should include and a budget to match, looking for validation rather than a full scoping process. We convinced them to run a proper discovery phase, including focus groups and user workshops with prospective residents. What we found was that the product needed to be far simpler than they had planned. Many features were dropped. The focus shifted to creating a human connection with the product rather than replacing the building's existing systems.

The result was a better product built for less. The discovery phase did not slow things down. It redirected the budget away from features residents did not want and toward the ones they would actually use. That is what genuine scope justification looks like: the user evidence drives the scope, not the founder's instinct about what a comprehensive product should contain.

A broader scope built on discovery is strategy. A broader scope built on assumption is optimism.

How to test whether you need a super app or a focused one

The test is not complicated, but it requires honesty. Start with the single most important thing your product does. If that one function were delivered exceptionally well, would users return for it alone? If the answer is yes, you have a core worth launching. If the answer is uncertain, no amount of additional features will fix that uncertainty. They will only make it harder to diagnose.

Then ask whether the additional functions you are considering create genuine dependency on the core, or whether they are independent services that happen to share an audience. Functions that create dependency belong together. Functions that share an audience do not automatically belong in the same product.

Run this test with the whole team in the room, not just the founder. The people closest to the product often hold the most expansive view of what it needs to be, and the test works best when it is checked against multiple perspectives.

Also consider what the context of use actually demands. We worked on a water tracking app that was originally phone-only, and later added an Apple Watch component. The watch experience could not simply be a reduced version of the phone experience. The navigation logic, the interaction model, and the amount of information on screen all had to be rethought from scratch for that context. The platform was different, the use moment was different, and the design had to follow. The same principle applies to feature combinations: context and emotional fit matter as much as functional capability.

Conclusion

The super app is a legitimate product model. It worked, and continues to work, in specific markets where the conditions support it. But the label travels too easily, and founders reach for it before they have answered the more basic question: does the thing they are building serve one user need exceptionally well?

The projects we have described here were not failures of talent or effort. The founders were capable and genuinely motivated. The problems came from scope that outgrew the evidence behind it, from features added before the core was validated, and from a reluctance to launch something focused in favour of launching something complete. That reluctance has a real cost, measured in budget spent in design and build, and in products that never reached the people they were made for.

A product that does one thing well and ships is more valuable than a product that does ten things adequately and does not. Discovery is how you find out which features actually matter. Launching is how you find out whether you got that right. Neither step can be borrowed from a competitor's roadmap or replaced by a confident spreadsheet.

If you are weighing up the scope of a product and want a clear-eyed conversation about what to build first and why, let's talk about your product scope.

Frequently Asked Questions