The phrase “super-app” is seductive. It suggests that one digital platform could become the gateway through which people move, buy, pay, communicate and participate in economic opportunity. In an investment proposal, however, the same phrase can conceal a serious fundability problem.
A venture may promise ride booking, deliveries, emergency response, marketplaces, payments, safety services, artificial intelligence and national reach before it has proved that any one transaction can be completed reliably between real participants. Breadth is then treated as evidence of scale, and projected scale as evidence of value. Neither inference is safe.
This article draws on anonymised professional assessment experience involving an ambitious South African mobility-platform proposal. It discloses no confidential configuration, financial assumptions or project identity. The wider question is more useful: how should an expansive platform vision be converted into a bounded, testable and fundable development programme?
A super-app is an outcome, not a starting specification
Successful multi-service platforms are usually examined after they have accumulated users, operating data, trusted payment relationships and capable partners. Looking backwards, expansion can appear to have been the original product.
In reality, platform growth normally rests on narrower transactions that worked often enough to support the next layer.
Rochet and Tirole’s work on two-sided markets explains why: a platform must attract interdependent participant groups and design rules that bring both sides on board. Each additional service adds another group, incentive, integration and failure path.
Network effects therefore do not rescue an unproven platform. They intensify its early coordination problem. The World Bank’s analysis of digital businesses emphasises that platforms provide governance, standards and protocols that enable interactions. The platform is not merely an attractive interface; it is an operating system for an exchange.
A crowded market raises the burden of proof
South African mobility is not an empty field awaiting the first app. International operators coexist with locally rooted or specialist initiatives such as Shesha, Drivo Africa, Khomba Taxi, AftaRobot and TaxiConnect.
These services do not all serve the same users, but their presence shows that booking, tracking, payments, driver tools and local positioning are not automatically differentiators.
The Competition Commission’s public-passenger-transport inquiry examined e-hailing within a market already shaped by metered taxis, minibus taxis, operating licences and uneven regulation.
A new venture must therefore answer a harder question than “Can we build an app?” It must show why a defined participant group will use its exchange rather than existing formal, informal or digital alternatives.
Start with the atomic transaction
The first discipline is to identify the smallest complete exchange through which the platform creates value—the atomic transaction. Who requests what from whom? What eligibility and identity rules apply? How are supply and demand matched and confirmed? How is the service fulfilled, recorded and settled? What happens when someone cancels, disputes or fails to perform?
This is not a retreat from ambition. It is the point at which ambition becomes engineering and operating design. If the core exchange cannot be stated clearly, the team cannot specify the architecture, allocate responsibility, design meaningful tests or calculate the economics.
A defensible entry point is usually bounded by a real service cell: one organisation, community, corridor, customer segment or use case with reachable participants and a recognisable unresolved problem.
A pilot must test a market interaction, not merely an app
For a conventional software product, an early version may be tested by individual users. A platform is different because value depends on interaction. A polished passenger application with too few suitable providers is not viable; a well-equipped provider application with too little demand is equally uninformative.
The relevant unit is closer to a minimum viable network: enough of each critical participant group, within a sufficiently contained environment, to test the complete exchange repeatedly.
The UK Government Digital Service’s alpha guidance advises teams to test their riskiest assumptions, including user adoption and integrations. For a platform, that means a controlled market-cell pilot with known supply-and-demand density, operating rules, service conditions and support arrangements.
Downloads and registrations are weak proxies for a functioning platform. A serious pilot measures successful matching, transaction completion, response time, repeat use, provider acceptance, cancellations, support interventions, safety incidents, settlement exceptions and contribution per transaction.
It also defines decision rules before testing: what result justifies the next tranche, what requires redesign, and what would show that the market is too thin or costly to govern?
The evidence must also be attributable and comparable. Transaction logs should connect requests, matches, fulfilment outcomes and exceptions without compromising personal information.
Baseline measures should show how participants currently solve the problem, so the pilot can demonstrate whether it improves cost, reliability, access or accountability. Negative results matter: they reveal where the operating model, participant incentives or technical architecture must change before more capital is committed.
Without this discipline, a pilot can become an open-ended demonstration in which activity is mistaken for validation.
Differentiate through the operating mechanism
A platform’s defensible difference may lie in how participation is governed rather than in how many functions appear on its menu. Where organisations, communities or structured provider groups are involved, the real capability may be the reliable administration of roles, consent, service rules, attribution, data boundaries, benefits and exceptions.
Such claims must become testable mechanisms. Who sets and changes a rule? Who may join or be removed? What information may each role see? How is a benefit calculated and audited? Which party is responsible when automation fails? Until those questions are answered and tested, “community ownership”, “shared benefit” and “platform governance” remain branding rather than demonstrated capability.
Regulation and data are part of the product
In mobility, regulation cannot be postponed until after the technology works. In September 2025, South Africa implemented national land-transport amendments that expressly introduced e-hailing as a service type. A pilot agreement, platform architecture and financial model are incomplete if they assume access to providers, routes, services or data that cannot lawfully be used.
The same applies to identity, location, trip, payment and safety information. The Information Regulator’s POPIA guidance requires reasonable technical and organisational safeguards. Consent, purpose limitation, access control, retention, incident response and responsibility between the platform and operators must be designed into the service—not added as a compliance appendix after the pilot.
Fund learning before scale
Development capital should be linked to the reduction of material uncertainty. Early funding can support competitor review, architecture and code assessment, intellectual-property clarification, regulatory mapping, user discovery, pilot contracting and construction of a testable transaction core. The next tranche should depend on evidence that these foundations are adequate.
Prototype and pilot funding can then support a controlled service cell with explicit acceptance criteria. Expansion capital should follow only when repeated use, operating reliability and plausible unit economics have been demonstrated.
The Technology Innovation Agency’s Technology Development Fund describes a progression from proof of concept through prototype to demonstration in an operating environment. The practical implication is clear: development funding should purchase maturation and evidence, not the premature appearance of national scale.
The decisive question
The super-app vision is not inherently wrong. The error is treating the final ecosystem as the first development specification. Each service brings another participant group, operating rule, integration, data responsibility and economic assumption. Complexity compounds long before network effects arrive.
A credible platform begins with one valuable exchange for a bounded group. The decisive question is not “How many services can this platform eventually contain?” It is: “What is the smallest complete market interaction we can prove, and what evidence must it produce before we add the next layer?” That is the route from an ambitious application concept to a platform that a responsible funder can evaluate—and, when the evidence warrants it, finance.
Author’s note: This article distils general lessons from anonymised professional assessment experience. It discloses no confidential project information and makes no claim that the framework has been implemented by a particular venture.
Share
