Building a 5-Branch Supermarket E-commerce Platform in Tanzania: M-Pesa, Map Delivery & WhatsApp Dispatch

Most e-commerce case studies are written by agencies who handed over a website and left. This one is different: I'm the branch manager of the supermarket chain this platform was built for. I process its orders, answer its customers, and dispatch its riders. When something doesn't work, I'm the first person it hurts.

That changes how you build. Here's the full story.

Why does a Tanzanian supermarket chain need its own e-commerce platform?

Jambo Supermarket operates five branches across Dar es Salaam: Mikocheni, Bahari Beach, Masaki, Bunju, and SalaSala. Our customers were already ordering online — just badly. They'd WhatsApp a photo of a shopping list, a staff member would walk the aisles collecting items, then a long back-and-forth about totals, delivery charges, and payment would follow. Every order consumed 20–30 minutes of staff time before a single item left the store.

Marketplace platforms weren't the answer either: commissions eat grocery margins, they control the customer relationship, and none of them handle a multi-branch operation where each store has its own catalog and delivery zone.

So the requirements were clear from day one — written by someone who would personally live with the consequences:

• Five branches, one platform — each branch with its own products and orders
• M-Pesa payments — because that's how Dar es Salaam actually pays
• Delivery pricing without phone calls — automatic, distance-based, transparent
• Rider dispatch in one tap — riders live on WhatsApp, so the system should too
• Admin roles that match a real org chart — owner, assistants, and branch managers see only what they should

How does the platform handle payments in East Africa?

Card payment gateways are the default answer everywhere else. In Tanzania, they're the wrong answer: card penetration is low, but nearly every adult carries mobile money. The platform runs a live M-Pesa payment flow, with cash on delivery as the fallback — matching how customers actually behave rather than how a Western e-commerce template assumes they behave.

This single decision matters more than any design choice on the site. An online store in East Africa that only accepts cards is a store with a locked front door.

How do you price delivery without arguments?

Delivery charges were the biggest source of friction in the old WhatsApp-ordering days. Too high and the customer cancels; too low and the store eats the cost; negotiate and you burn staff time on every single order.

The platform's answer: at checkout, the customer drops a pin on a map. The system measures the distance from the selected branch and applies a distance-based delivery charge automatically. The customer sees the exact total before confirming. No calls, no negotiation, no surprises — and no staff time spent.

What happens after an order is placed?

This is where most e-commerce builds stop and real operations begin. An order that sits unseen in an admin panel is a cancelled order. The flow we run:

1. The order lands in the branch's admin panel with its map pin, items, and payment status.
2. Staff pick and pack the order.
3. The dispatcher presses one button — WhatsApp rider dispatch — and the rider instantly receives the order details and delivery location on WhatsApp, the app already open on every rider's phone.

No rider app to install, no rider training, no printed slips. We built the system around the tool riders already use, instead of forcing a new tool on them.

How does a 3-tier admin panel keep 5 branches under control?

Multi-branch retail has a permissions problem: the owner must see everything, but a branch manager should only touch their own branch. The platform uses three role tiers:

• Superadmin (owner): full visibility and control across all branches
• Assistant: scoped to the specific branches assigned to them
• Branch manager: their branch only — products, orders, deliveries

One detail I'm particularly proud of: the owner account is protected at the database level. A database trigger makes it impossible to delete or demote the owner — even by someone with admin panel access, even by a mistake in the database console. In a business, software security that depends on everyone clicking carefully is not security.

What about customer loyalty?

The platform includes a loyalty card program with automated email delivery — a customer signs up, and the system generates and emails their card automatically (built on Resend with a serverless function). Retail margins are thin; repeat customers are the business. Making loyalty enrollment zero-effort for staff was the requirement, and automation was the answer.

What's the technology stack — and what does it cost to run?

The platform is built on React (Vite) + Supabase (Postgres) + Cloudflare Pages. The reasoning:

• Supabase gives a real Postgres database with row-level security — which is how branch scoping and the owner-protection trigger are enforced at the data layer, not just in the interface.
• Cloudflare Pages serves the site fast on Tanzanian connections and costs almost nothing.
• Resend + serverless functions handle transactional email (loyalty cards) without running a server.

One war story worth sharing: mid-project, the site became unreachable for many local customers — Tanzanian ISPs were silently blocking the hosting provider's default subdomains. Diagnosing an invisible, ISP-level block and solving it (custom domain with a corrected DNS setup) is exactly the kind of problem you only learn deploying in Africa, not deploying for Africa from somewhere else. If your developer has never dealt with this, their first production incident will be on your project.

What did we learn building it?

• Build around existing behavior. M-Pesa because customers have it; WhatsApp dispatch because riders live there. Adoption problems are usually design problems.
• Enforce rules in the database, not the interface. Branch scoping and owner protection live in Postgres row-level security and triggers — the interface can have bugs; the data layer holds the line.
• Delivery pricing is a product feature, not an afterthought. Automating it removed our single biggest source of order friction.
• Local conditions are technical requirements. ISP quirks, connectivity drops, and mobile-first customers aren't edge cases here — they're the spec.

Frequently asked questions