A 3G connection that drops in the lift. A phone with 2GB of RAM and forty WhatsApp groups fighting for storage. A data bundle the buyer counts in megabytes. Payment in cash, at the door, after the customer has opened the box and checked that the shoes fit.
None of that is an edge case in Lagos, Nairobi or Accra. It’s the median user. And it’s why scalability in these markets is decided by constraints, not by server capacity. You can rent almost unlimited compute in an afternoon. You can’t rent a buyer who trusts a stranger with ?45,000 before the parcel arrives. Copy the Silicon Valley playbook and it breaks at the first constraint it meets, usually long before traffic gets anywhere near your database limits.
I’ve spent most of the last decade building marketplace products for markets like these: two-sided platforms for consumer goods, home services and B2B supply. The failures I watched were almost never about load. They came from a checkout that assumed cards, an onboarding screen that assumed a national ID, and a delivery promise that assumed street addresses.
Most marketplaces here die of assumptions, not traffic
“Build it like Amazon and scale later.”
You hear some version of this at every investor demo day. Get the architecture ready for ten million users, the argument goes, and the market will catch up.
It sounds disciplined. It’s backward. Amazon’s model grew up around customers who already had cards, fixed addresses, fast home internet, and a postal system that worked. Scaling it later means scaling a set of assumptions that were wrong on day one. The microservices will be fine. The product sitting on top of them won’t fit the person holding the phone.
What I push teams toward instead is constraint-first architecture. You write down the hard limits of your real users before you pick a stack, and every major technical decision has to answer to one of them. Bandwidth budget first. Payment mix second. Trust mechanism third. The cloud diagram comes last, and it’s usually the easy part.
The data backs this order. GSMA’s Mobile Economy Africa 2026 report found that almost 1 billion people in Africa, or 63% of the population, were still not using mobile internet in 2025, despite widespread network coverage. In Nigeria, DataReportal counted 109 million internet users at the end of 2025, a penetration rate of 45.5 percent, and only 69.0 percent of the country’s 165 million cellular connections counted as broadband. On the money side, the World Bank’s Global Findex 2025 shows account ownership in Sub-Saharan Africa rising to 58% of adults in 2024, up from 49% in 2021, with mobile money use at the highest level of any region.
Put those side by side. The market is growing quickly, and a big share of it arrives on a patchy connection, a modest handset and a mobile wallet rather than a card.
If you’re bringing in outside engineers for the build, pick a team that has shipped marketplace platforms under these limits, not one that wants to port a US template with a naira sign on it. LITSLINK is one I’d put on a shortlist. Its marketplace page explains how the team scopes these builds, and you can read more here. Whoever you hire, ask to see their bandwidth budget before their architecture slides.
Connectivity and device limits pick your stack before you do
The default playbook: a heavy single-page web app, a 60MB native install, full-resolution product photos and a client that assumes it’s always online.
What works here: offline-first clients, small installs, ruthless image compression and channels that don’t need a smartphone at all.
The moment this clicked for me was on a B2B ordering app for small shop owners. A trader in Onitsha showed me her phone. She had deleted our app the week before to make room for photos of her own stock, and she’d gone back to ordering over WhatsApp voice notes. Our analytics called it churn. It was a storage problem.
So the client has to earn its place on the device. Cache the catalog locally in SQLite or IndexedDB and sync deltas, not full lists. Queue writes when the signal drops and replay them when it comes back. Make every order and payment endpoint idempotent, because a retried request on a flaky network should never create a second order or a second charge. Serve images in two or three sizes in WebP and let users switch on a data saver mode that hides them until tapped.
Then go below the app. USSD still matters for order status, confirmations and simple reorders, especially for sellers and agents on feature phones. The sessions are short and unforgiving, so the menu tree has to be shallow. WhatsApp is the other channel people underrate. The WhatsApp Business Platform handles catalog links, order updates and support threads in an app your users already keep open all day. A lot of marketplaces I’ve seen get more repeat orders from a well-run WhatsApp flow than from push notifications.
Payments have to meet money where it already lives
The default playbook: card checkout, charge at the moment of order, refunds back to the card.
What works here: mobile money, bank transfer, USSD and cash on delivery, all feeding one ledger, with seller payouts held until the buyer confirms.
In Kenya, that means M-Pesa from day one. In Ghana and much of East Africa, MTN MoMo and Airtel Money. In Nigeria, bank transfer is often the real default, with cards and USSD behind it. Paystack and Flutterwave bundle most of these methods behind one integration in the countries they cover, which saves months of work. I’d still keep a second provider wired in. Outages happen, and a payment method that fails on a Friday evening costs you buyers who don’t come back.
Cash on delivery won’t disappear just because you’d like it to. Jumia’s own results for the second quarter of 2025 show JumiaPay payment volume holding at 27% of gross merchandise value, and the same filing lists the gradual conversion of cash on delivery orders into prepaid orders as a goal. That suggests most of the value on Africa’s best-known e-commerce platform still settles outside its wallet, a lot of it at the doorstep. That last part is my inference from the filing, not a figure Jumia publishes.
The lesson for builders is boring and important. Your ledger is the product. Use double-entry accounting from the first commit, record cash collected by each rider as a liability until it’s deposited, and reconcile daily. For escrow-style protection, hold seller payouts until a delivery window closes, but don’t hold customer funds in your own bank account unless you have the license for it. Split payments and subaccounts at a licensed provider do the job without turning you into an unlicensed bank.
Trust is the real conversion rate
The default playbook: star ratings, email verification and a hard government ID check at signup.
What works here: phone-based identity, tiered verification, behavior-based badges, human agents and the right to inspect before you pay.
Ratings are thin when a marketplace is young and gamed once it isn’t. I’ve had better results showing the count of completed orders and repeat buyers next to a seller’s name than showing stars. A seller with 212 completed deliveries and 40 repeat customers tells a buyer more than 4.7 stars from people nobody knows.
Identity needs tiers, because ID coverage is patchy and an ID wall at signup kills growth. Let people browse with nothing. Let them buy with a phone number and an OTP. Ask for BVN or NIN in Nigeria, or the national equivalent elsewhere, only when someone wants to sell or withdraw money. That puts the friction where the fraud risk actually sits.
Then there are agents. M-Pesa grew on the back of people standing in shops, turning cash into digital value for neighbors who trusted them. Marketplaces can borrow the model. Field agents who onboard sellers, photograph stock, check that a shop exists and vouch for it do more for trust than any algorithm I’ve shipped. Pair that with open-box inspection at delivery, and buyers stop treating every order as a gamble.
Logistics sets your margin, and most of it happens outside the app
The default playbook: a same-day promise, a street address field and an in-house fleet.
What works here: landmark-based addresses, pick-up points, third-party riders, delivery windows and real plans for orders outside the big cities.
The growth isn’t only in Lagos. In the same Q2 2025 report, Jumia said 59% of its orders came from upcountry regions, up from 52% a year earlier, and put fulfillment expense at $2.19 per order. That second number is a floor. It has to sit inside your pricing, your minimum basket size and your seller commission, or every new order loses money a little faster.
Addresses need rethinking too. “Opposite the filling station, second gate, blue roof” is a perfectly good address if your system stores it next to a GPS pin and a phone number, and your rider app lets the rider call the buyer in one tap. Build the rider app to work offline, capture photo proof of delivery and log cash collected per drop. Track failed delivery attempts as a core metric. In my experience, it’s the number that tells you, months before your P&L does, whether the marketplace will survive.
Pick-up points belong in version one, not version three. A pharmacy, a phone shop or a petrol station that holds parcels for a small fee cuts failed deliveries, gives cash buyers a safe handover spot and costs far less than a second fleet.
Regulation is a product requirement, not a legal afterthought
The default playbook: launch first, hire counsel after the Series A and store everything in one foreign cloud region without asking.
What works here: mapping data flows on day one, using licensed partners for anything that touches money and designing verification rules you can tighten by configuration.
Nigeria’s Data Protection Act became law in June 2023 and set up the Nigeria Data Protection Commission as the regulator. It limits transfers of personal data outside the country unless the destination offers adequate protection, and its fines scale with annual gross revenue. Kenya has had its Data Protection Act since 2019, and Ghana since 2012. If you run one platform across these markets, you need to know where every buyer’s phone number, address and BVN lives, and who can read it.
Money rules move faster. On April 29, 2024, the Central Bank of Nigeria told OPay, Moniepoint, Kuda, Palmpay and Paga to stop onboarding new customers while they tightened KYC and fraud controls. The pause was lifted in early June, with conditions that included physical address verification. If your marketplace onboards sellers through one of those partners, your growth stops the same day theirs does.
The fix is architectural. Keep verification rules in configuration, not hard-coded flows, so a new requirement means a settings change instead of a two-sprint rebuild. Keep two payment partners live. Log consent properly. None of this is glamorous, but it’s the difference between a bad week and a dead quarter.
A constraint-first roadmap for the first 18 months
Here’s the whole argument on one page before the plan.
| Constraint | Default playbook | What works here | Example company
|
|---|---|---|---|
| Connectivity and devices | Heavy web app, always online | Offline-first client, small install, USSD and WhatsApp channels | M-Pesa (runs on feature phones through SIM menus) |
| Payments | Card checkout, charge at order | Mobile money, transfer, USSD and cash on delivery in one ledger | Paystack, Flutterwave |
| Trust | Star ratings, ID wall at signup | Tiered verification, field agents, open-box inspection | Moniepoint (agent network) |
| Logistics | Same-day promise, street addresses | Landmarks plus GPS pins, pick-up points, third-party riders | Jumia (upcountry orders) |
| Regulation | Launch first, lawyer later | Licensed money partners, data mapping, configurable KYC | Fintechs paused by the CBN in 2024 |
1. Months 0 to 3: prove the constraints, not the scale
Pick one city and one category, and write your constraint sheet before you write code: target device, bandwidth budget per session, payment mix and delivery radius. Ship a lightweight Android app or PWA with cash on delivery and one licensed payment provider, and run order updates through WhatsApp. Recruit your first sellers by hand, with agents if you can afford them. The only metrics that matter here are completed orders, failed deliveries and repeat buyers.
2. Months 3 to 9: build the ledger and the trust layer
Move to a proper double-entry ledger, add held payouts, and wire in the second payment provider. Launch tiered verification and replace stars with completed order counts and repeat buyer signals. Add pick-up points and a rider app that works offline. This is also when you map every data flow against the Nigeria Data Protection Act and the rules in each market you plan to enter.
3. Months 9 to 18: expand by constraint, not by country count
Enter the next city or country only after you’ve rewritten the constraint sheet for it, because Nairobi’s payment mix and Kano’s delivery realities are different problems. Add USSD for sellers and agents, introduce data-light features such as text-only browsing, and start splitting services where load actually demands it. By now the cloud bill will finally be worth optimizing, which tells you how far down the list it belonged.
The marketplaces that scale here are the ones that treated every constraint as a spec, long before they treated traffic as a problem.