Mobile + web · Services marketplace / Android + web
A marketplace is built around trust and follow-through.
Helping customers find local providers, with requests, messaging and job progress in one place.
The problem
Finding a service provider is just the first step. Customers need to make a request, know who accepted it and keep the conversation and job progress connected.
What I owned
Provider discovery and onboarding, location-aware requests, messaging, notification flows, Android releases, web acquisition and analytics.
The difficult constraint
Discovery should show eligible real providers. Competing offers need a single winner, messages should unlock at the right time, and notification delivery must remain distinct from an attempted send.
The architecture
React Native 0.81 / Expo 54 powers Android. A separate Next.js browser marketplace shares domain contracts with the mobile application. Supabase/PostgreSQL policies, RPCs and lifecycle rules coordinate provider, booking, review and safety-report data.
A product decision
Let a customer complete the request before sign-in, save its draft in session storage and restore it after authentication. The source explicitly preserves that work so account creation does not erase intent.
Reported adoption
The September CV reports a historical milestone of 1,000+ Play downloads and 120+ providers. The repository documents a pilot across Nairobi, Kisumu and Mombasa. These are dated milestones, not live user counters.
What this taught me
A contact tap, a submitted request, a provider acceptance and a completed job mean different things. Product analytics and operations need those distinctions to understand whether the marketplace is actually helping people.
Evidence & scope +
- Mobile manifest verifies React Native 0.81.5, Expo 54 and React 19.
- README describes the three-city pilot and first valid acceptance lifecycle.
- create-request-form.tsx directly implements authentication-safe draft retention; adoption is CV-reported.