Back to work

Live on iOS

Mosebetsi

A two-sided task marketplace for South Africa. I designed and built the platform end to end across 39+ development phases. It is live on iOS and on the web at mosebetsi.co.za, with Android coming soon.

01 Problem

South Africa has high unemployment and a large informal labour market, but no trusted, general-purpose way to connect people who need tasks done with local workers who can do them safely and get paid reliably.

02 Approach

I led the development of a two-sided marketplace across 39+ development phases. It shipped on iOS, the web platform is live at mosebetsi.co.za, and Android is coming soon.

03 Architecture

React Native (Expo) and React on the front, Firebase (Auth, Firestore, Cloud Functions, Storage) and Node.js on the back. The platform runs five role-based dashboards (Client, Tasker, Verified Client, Verified Tasker, Admin), KYC identity verification, a real-time task lifecycle, OTP auth via Africa's Talking, push notifications, and Google and Apple Sign-In. I designed and built the wallet and payment flow on top of third-party payment infrastructure, then rebuilt it across several iterations to work within the real constraints of South African banking and payments.

  • Five role-based dashboards: Client, Tasker, Verified Client, Verified Tasker, Admin
  • KYC identity verification
  • Real-time task lifecycle
  • Wallet and payment flow integrating Ozow, rebuilt across several iterations
  • OTP auth via Africa's Talking
  • Push notifications
  • Google and Apple Sign-In
The Mosebetsi web platform home page. The headline reads Get it done today, hire trusted ID verified locals, above buttons to post a task or browse tasks
The Mosebetsi How It Works page, stepping through posting a task, taskers applying, choosing one, and rating the work
The Mosebetsi sign-in screen, offering Google sign-in or a South African phone number for a one-time passcode

04 A decision I am proud of

The security audit I did not have to do. Mosebetsi has five role-based dashboards, each with its own permissions. Testing after I deployed the Firebase Authentication and Firestore security rules, I found that one specific sequence of actions let a user in one role reach data they should never have been able to see. Patching that single path would have taken a few minutes and closed the ticket. Instead I audited every security rule across the whole database, found the remaining edge cases, and rewrote the rules to be explicit and deny by default rather than allowing whatever was not specifically blocked. Then I built a test checklist that has to pass before any rule change goes out, so the same class of problem cannot come back quietly. The path I found was only one path. The ones I had not found yet were the reason to go through all of it.

05 Outcome

A live iOS app, a working web platform, and a beta tasker programme running in the Randburg, Sandton and Rosebank areas. This is early-stage, and the focus now is the beta rather than vanity metrics.