How a chat app kept working where WhatsApp could not
Chat, a wallet and a marketplace behind one login, for a country still on 2G and 3G where there was no digital payment system to build on. Fifty thousand people downloaded it in the first couple of weeks.
- 2G and 3G
- the mobile networks it is built to work on
- 50,000
- downloads across both stores in the first weeks
- 4
- products behind one login: chat, wallet, marketplace, events
- Company
- Undisclosed
- Industry
- Consumer messaging and payments
- Company size
- 5 to 10
- Location
- Africa
Challenge
The client wanted several products in one app for a market where most of the usual assumptions do not hold. The hard part was never the feature list. It was that every one of those features had to work on a connection that modern software is built to ignore.
Phones on 2G and 3G
Users are on mobile networks a generation or two behind what an app of this kind assumes, and they are unstable as well as slow. WhatsApp is what people already had, and it is built for a connection that holds. On these it does not.
No digital payments to plug into
The country had no established digital payment system. That removes the ordinary answer, which is to integrate a provider and put an interface on it. There was nothing underneath to integrate with.
No marketplace either
Buying and selling was happening across chat threads and in person, with no common place to list anything. The client wanted that in the same app rather than in a second one nobody would install.
Four products on one bandwidth budget
Chat, wallet and marketplace at launch, with events added later. Every one of them had to fit the same connection. A single heavy screen anywhere in the app undoes the work everywhere else, because the user judges the whole thing by the worst part of it.
Nobody can tell the app from the line
On an unstable network a user blames whatever is on screen. An app that is genuinely fast on a bad connection still gets uninstalled if the connection dies mid-message and the app is the only thing there to blame.
A client team of five to ten, mostly marketing
There was no engineering team on the client side to hand a fleet of systems to. Whatever shipped had to be something a small marketing team could run and promote without an operations department behind it.
What we built
Almost every decision here was settled by the same question: what does this cost on a 2G connection. The answers run in the order the problems were listed.
The whole stack tuned to the network
This was not a matter of compressing images at the end. Every layer was chosen and tuned against the bandwidth budget, because on a connection this narrow the slowest part of the stack sets the speed of the product. That work is invisible when it succeeds and it is the entire engagement.
The wallet is the payment system
With no provider to sit in front of, the wallet had to be the thing that holds and moves the money rather than an interface onto something that already did. For a lot of users this is the first digital payment they have made.
A marketplace on the same budget
Listings, browsing and buying were built to the same constraint as the chat rather than treated as a richer surface that could afford more. A marketplace that only loads on a good connection is a marketplace for the people who already had one.
One download, four products
Chat, wallet and marketplace ship as one app, and events joined them later under the same rules. One install, one login, one thing to keep updated over a slow connection - which matters more here than it would anywhere else.
The app measures the connection itself
There is a page inside the app that tests the user's own network speed. It looks like a small feature and it settles an argument the product cannot otherwise win: it lets somebody see the line is at fault, rather than deciding the app is broken and removing it.
Several systems collapsed into one
Everything the client would otherwise have run separately sits in a single application. That is a smaller surface for a five to ten person team to operate, and it is the difference between a product they can manage and one they would need to hire for.
What changed
The client promoted the launch at national level and the audience arrived within days. What the reviews talk about is not the feature list.
Fifty thousand downloads in the first weeks
Across Android and iOS, within a couple of weeks of launch, in a market where a heavy app would not have finished installing on most connections.
The reviews are about the speed
More than a hundred reviews arrived in the same period, and what users keep saying is that it works on their connection. That is the one piece of feedback that tells us the constraint was the right thing to build around.
Events shipped under the same constraint
Events were added after launch and had to meet the same bandwidth budget as everything before it. It went out without loosening the rule the rest of the app was built on, which is the test of whether that rule was real.
Let AI do the repetitive
half of the job.
Data entry, answering the same tickets, chasing numbers between systems. We automate the parts that repeat. Your team keeps the parts that need judgement.
