The Problem
SOS needed a marketplace that worked for four completely separate user groups, each with a different job to do. A single multi-role app would have meant constant compromise: features and navigation built for nobody in particular. The product question was whether to build one flexible app or four focused ones.
Overview
SOS Marketplace is an e-commerce platform built for the Cameroonian market. It covers the full order lifecycle: a customer places an order, a vendor prepares it, a rider picks it up, and an admin oversees the whole operation. Each part of that process has its own dedicated app.
Rather than one app that tries to do everything, the product was structured as four separate web portals and four native mobile apps, one per role. The reasoning is straightforward: a vendor's job looks nothing like a rider's job. Trying to serve both in the same interface would mean watered-down features and navigation built around nobody's actual workflow.
My Role
- Defined the product architecture across 4 web portals and 4 mobile apps, each scoped to a specific role and user job
- Owned the product roadmap and kept delivery on track across frontend, backend, and mobile teams simultaneously
- Designed the full order flow from customer checkout through vendor fulfilment to rider pickup and delivery confirmation
- Shaped the go-to-market approach for the Cameroonian market, including offline-tolerant features and local payment method support
- Led stakeholder alignment across user groups to ensure each role-specific app reflected how that group actually worked, not how we assumed they worked
Stakeholders
- Customer, vendor, rider, and admin user groups (each with distinct requirements)
- SOS business stakeholders
- Frontend and backend engineering team
- Mobile development team
- QA across 8 separate app surfaces
Key Decisions
Challenges
Discovery
The client's ambition was to be a pioneer for every major industry in Cameroon, and e-commerce was the starting point. The validation was as much qualitative as formal. No existing platform in the market covered the full order lifecycle end to end: platforms that handled listings did not handle logistics, and those that handled logistics had no marketplace. The four-role architecture came from mapping who is physically involved when a real order happens: a customer places it, a vendor prepares it, a rider collects and delivers it, and an admin oversees the whole operation. The structure followed the actual workflow rather than a product convention.
Stakeholder Friction
There was early internal pressure to launch with just a customer and vendor experience and add the rider app in a later phase. The argument for phasing was speed to market. The counter-argument was that without the rider layer in the first version, delivery coordination would default back to WhatsApp, which would make the platform's core value proposition hollow. A marketplace with no delivery layer is a listings board. That argument held, and all four surfaces launched together.
Outcomes
Technology Decisions
What I'd Change
I would have pushed for a tighter onboarding process for the initial vendor cohort before opening registration more widely. The first wave of vendor signups had inconsistent listing quality, and some of the early customer friction came directly from that. Getting the first 20 vendors deeply embedded and producing high-quality listings before scaling would have set a better standard for everything that followed.