(02) The Context
The problem
- Manual ROSCA processes were slow and error-prone.
- Members had little transparency into contributions and payouts.
- Administrators had no central place to manage groups.
- Different roles needed different interfaces and permissions.
(03) My Role
My contribution
- Project manager for the project
- Designed and implemented frontend architecture.
- Built the user-facing application.
- Built admin and super-admin interfaces.
- Developed reusable UI components.
- Implemented state management.
- Integrated APIs and financial workflows.
- Worked on wallet and savings experiences.
- Collaborated with backend/product stakeholders.
- Improved responsiveness and usability.
(05) The Engineering
One monorepo, three apps: separate user, admin and super-admin applications, free to evolve independently, with a clear permission model per role — consistent where it matters, without forcing every experience through the same interface.
apps/user
Member app
Onboarding, KYC, joining ROSCAs, contributions, payouts, wallet.
apps/admin
Admin app
Running groups and cycles, centralised day-to-day operations.
apps/super-admin
Super-admin app
Platform-wide oversight across admins and communities.
Shared foundation
React · TypeScript · Vite · Tailwind · Zustand
(06) The Product
What it does
(07) Challenges & Decisions
The challenge
Three kinds of user with very different jobs and permissions, in one product that has to feel trustworthy with people's money.
The decision
Separate the experiences by role (user, admin, super-admin) so permissions stay clear and each app can be developed independently.
(08) Results
Impact
- 3 application interfaces delivered
- Multiple financial workflows implemented
- Admin operations centralised
- Product prepared for production deployment
(09) What I Learned
This went well beyond UI. I learned how financial workflows, permissions and trust mechanisms work — and how product architecture shapes the way people behave.
Next case study — 02