Mobile Super Apps and Mini-App Platforms

The difference between an app that is needed and an app that is opened

A banking app is somewhere a customer goes when they have a reason. Check a balance, pay a bill, send money, close it. That is why the icon ends up three screens deep on most phones. What stays on the first screen here sits in the middle of daily spending: fares, airtime, a shop, money to family. Mobile money got there by being where money is spent rather than where it is kept.

A super app moves into that position deliberately. Instead of another banking feature, you bring services your customers already buy into your app: transport, bills, insurance, tickets, retail, government charges. These partner services are often called mini-apps. The name matters much less than the commercial arrangement behind them.

Frequency is the return. An app opened several times a week is where a card, a savings product or a loan offer is seen rather than posted, and it earns from other people's transactions as well as your own. It matters most where customers already have somewhere else to go: a telco defending daily attention against banks arriving with better financial products, or a bank holding the relationship and the balances without the frequency.

Two things you need before this is worth attempting

Be clear about the risk first. This is the most ambitious platform we build, and when it fails the reason is almost never engineering. It needs two things nobody can build for you: customers who already open your app, and partners who want your distribution enough to work to your standards.

The first is the harder test. Partner services multiply engagement, they do not create it. If your app is opened rarely today, adding ticketing gives you an app still opened rarely, with more to maintain and a partner wondering where the volume went. That institution gets more from making its banking app worth opening, and we would rather say so early than halfway through a build.

The second test is commercial. A partner joins because reaching your customers through you is cheaper than reaching them alone, and one with its own strong app will take the meeting and never do the work. A fintech may be building the super app as the business itself, which makes partner supply its main risk. For most SACCOs and microfinance institutions, a membership counted in thousands is not distribution a serious partner will negotiate for.

What a customer does inside it

Your own services stay at the centre: accounts, transfers, payments, cards, savings and loans. Around them sit the partner services, and the list should follow what your customers spend on rather than what looks impressive. Transport and fares. Utility and television bills. School fees. Insurance bought and claimed against. Travel and event tickets. Retail and delivery. Agricultural inputs. Health services. Government charges.

Customers buy through your app rather than the partner's own because everything around the purchase is already settled: no new account, no new details to type, and the money comes from an account they hold with you. Purchases sit with the rest of their spending, and when something goes wrong there is one place to raise it.

Around that sits the ordinary work of a marketplace: finding a service, keeping favourites within reach, receipts, refunds and rewards. Which categories launch first is decided with you, and should follow your customers' spending rather than the partners quickest to sign.

None of this replaces your other channels. Customers on feature phones, at agent counters and in branches will never see it, and should still meet the same products, limits and charges. What is different is that your app now carries somebody else's business alongside your own, and customers do not separate the two.

The partner programme is the product

Most of the work in a super app is not the part customers see: it is running a partner business, and institutions that treat that as a feature release find out late. Admission is the first decision: one category, several candidates, and a choice between a single partner on exclusive terms or several with customers picking. Exclusivity is worth real money to a partner and costs you bargaining power for years.

Then the economics. A partner can pay for placement, share commission on each sale, pay for the payment itself, or pay nothing at launch because you need them more than they need you. What you do not want is to find in the second year that the programme has never funded itself.

Then ownership of the customer. A partner will want to know who bought from it, and your customers' information is not yours to hand over on the strength of a commercial agreement. Tanzania has a Personal Data Protection Act, and what a partner receives, what the customer is told, and how consent is given and withdrawn are positions for your legal and compliance functions to take before the first agreement is signed.

Then quality, the risk most institutions underestimate. A service bought inside your app is, to the customer, something you sold them. When a delivery does not arrive or a ticket is not honoured, the complaint reaches your contact centre and attaches to your name. So you need service standards in the agreements, a way for customers to complain about a partner, someone watching how partners perform, and the willingness to remove one.

What has to be settled on your side

The build is rarely the long pole. Signed partner agreements are. Each is a separate negotiation with its own pricing, service commitments and legal review. The common failure is a finished app waiting while the first partners are still with the lawyers.

Some of what you would distribute is regulated in its own right. Insurance, credit and investment products are supervised separately from banking, and presenting them can carry obligations whether you are selling, introducing or only displaying somebody else's product. Banking itself is supervised by the Bank of Tanzania, and an institution putting third party services under its own brand should expect questions about it. Settle those positions before a category is designed around it.

Then the team, the piece most often missing. A partner programme needs someone to recruit partners, someone to negotiate and hold the agreements, someone watching performance and complaints, and support staff who can answer a customer about a service your institution did not provide. That is a standing commercial function, not a project role that ends at go-live. Without an owner, the app fills with whoever was easiest to sign.

What working with us involves

We start with discovery: who your customers are, how they use what you already run, what they spend on elsewhere, and which partners have a reason to work with you. You get a scope and a plan you own, whether or not we build it. If the honest answer is that your banking app should be better before it becomes a marketplace, we will say so.

Through delivery you see working software in an environment you control rather than status reports, and the source code and documentation are yours from the first commit. We will argue for launching with a few partners in categories your customers already spend on, because terms are easier to correct with three agreements than thirty. Afterwards we support the platform and train your people, including the team running the programme. There is no lock-in, by design and by contract.