-
-
landing page/home screen
-
daily check in
-
authority and statistics dash
-
desktop webapp
-
app icon
Inspiration
Tumaini (Swahili for "hope") is an ethical, mobile-first mental health platform built for urban communities where stigma often keeps people from seeking support in the open. Rather than a single monolithic app, it's structured as a set of role-based microservices—because mental health support isn't one-size-fits-all. A teenager looking for anonymous peer support has completely different needs from a licensed therapist managing a caseload or an NGO safety officer who needs to act fast on a credible abuse report.
(Personalize this paragraph with your own "why"—what made you want to build this specifically for urban Kenya/your community?)
What it does
Tumaini supports five distinct roles, each with a tailored experience:
Members join anonymously under an alias, access peer groups, and have access to a wellness/content library. Peer Guides (Counsellors) moderate group chats and can trigger a safety escalation flow that generates a script for handling at-risk users in real time. Therapists set availability and receive booking requests directly from the Connect section. Authorities (police, NGO safety officers) get a Command Center with geolocation heatmaps and critical abuse reports—access that's deliberately gated and only assignable by an Admin. Admins manage the whole system, including promoting standard users up to authority when verified.
How I built it
The stack is a Node.js/Express backend with MongoDB for persistence and a React + Vite frontend. A few design decisions mattered a lot:
*Bootstrap-first admin creation—rather than seeding a database with a default admin account (a common security smell), the Super Admin account is created the *first time anyone logs in with the reserved admin email, and whatever password is entered becomes permanent. This avoids shipping a known default credential.
**Role escalation via Admin, not self-service—Authority accounts can't be self-registered; they're either created directly by an Admin or upgraded from an existing Member account. This keeps sensitive access (geolocation data, abuse reports) behind a deliberate human decision.
**Separation of concerns between backend and frontend dev servers—Vite proxies frontend requests to the Express backend at localhost:3001, keeping the two loosely coupled during development.
Challenges I faced
Balancing anonymity with safety. The hardest tension in the whole project: members need to feel safe being anonymous, but peer guides need enough signal to escalate a genuine crisis to someone who can act. The Safety button/escalation script was my attempt to bridge that gap without breaking anonymity by default. Getting role-based access right. With five roles and very different permission boundaries (especially Authority vs. everyone else), making sure escalation paths couldn't be self-granted took real care. Local dev friction. Running two servers concurrently, keeping the Vite proxy config in sync with the backend port, and stale LocalStorage causing login loops when testing multiple roles in one browser session were all recurring headaches during testing.
Accomplishments that we're proud of
- Shipping a working five-role permission system where the most sensitive role (Authority) can only be created through a deliberate admin action, not a public signup flow
- Designing an escalation path (the Safety button) that gives Peer Guides a concrete tool in a crisis moment, instead of leaving them without recourse
- Getting a full anonymous-identity system working end-to-end—alias-based accounts that never expose a member's real identity to other members
What we learned
Building Tumaini pushed us to think seriously about designing for trust in a sensitive domain—every permission boundary had to be justified not just by "who should see this" but "what happens if this leaks or is misused." We also came away with a much sharper sense of how to structure role-based access control cleanly across a multi-sided platform and how much dev-environment friction (proxies, local storage, session state) can quietly become a UX problem if left unaddressed.
What's next for Tumaini peer support
- Moving from local MongoDB to a managed, encrypted database for production use
- Building out real-time notifications for booking requests and safety escalations
- Expanding the content library with localized, culturally relevant wellness resources
- Piloting with a real peer-counselling organization to validate the escalation workflow with actual safety officers
Log in or sign up for Devpost to join the conversation.