LindaKazi

LindaKazi landing page
LindaKazi gig worker dashboard
LindaKazi landing page
LindaKazi client dashboard.
LindaKazi auth page

Inspiration

Kenya's informal gig economy has a trust gap that cuts both ways. Clients inviting a stranger into their home have no reliable way to verify who that person actually is, identity fraud and unverified workers are a real risk. Workers doing domestic and gig work face the opposite problem: walking into a stranger's home alone, often with no smartphone or data plan, and no way to call for help if something goes wrong. About 80% of informal gig workers operate without any identity verification or safety net at all. We wanted to build something that protected both sides of that transaction, using the infrastructure that already reaches everyone in this market, USSD, SMS, and voice, not just smartphone apps that assume constant data access.

What it does

LindaKazi is a two-sided trust and safety layer for gig work.

For clients: a verified digital passport system checks worker identity and SIM-swap history before a booking is confirmed, so clients aren't left guessing whether the person arriving at their door is who they say they are.

For workers: once a gig is booked, a risk pipeline runs, a live SIM-swap check, rule-based scoring on KYC status and community rating, and an AI risk classification, before the job starts, with the result sent straight to the worker's phone by SMS. Once a gig is active, a check-in state machine tracks them: not started → awaiting → checked in or missed. A missed check-in automatically opens an SOS event and fires an emergency SMS to a designated contact. No app download, no smartphone, no data plan required on either side.

How we built it

Frontend: React + TypeScript in a Turborepo monorepo, with role-gated dashboards — a client view for booking and verifying workers, and a worker view for gig lifecycle and safety controls
Backend: Node.js/Express, with Zod-validated routes for gig creation, risk-checking, and lifecycle transitions (start, check-in, simulate-timeout, resolve-sos)
Database: Postgres via Drizzle ORM on Supabase, with a schema built around users, gigs, risk checks, and SOS events
Risk pipeline: a live SIM-swap check feeds a deterministic rule-based scorer, then Gemini AI classifies the result into a risk tier in under 5 seconds, with a rule-based fallback if the API call fails, so the pipeline degrades gracefully rather than breaking
Messaging: Africa's Talking for SMS and voice, pre-gig risk alerts to workers, automated SOS dispatch, and DTMF keypad SOS (worker presses '9' to trigger escalation)
Auth: Supabase-backed, with middleware that validates JWTs and checks gig ownership so a client or worker can only touch records that are actually theirs

Challenges we ran into

Getting the two sides of this system to work together correctly was harder than building either side alone.

Auth was the long pole. Our login flow started as a placeholder that never called the real backend, which meant every downstream authenticated request, client or worker, was silently broken until we traced it back to the source.
Response shape mismatches. Our backend nested the login payload one level deeper than our frontend types expected, a bug that fails quietly rather than loudly.
Demo data needs its own auth path. Because our auth is Supabase-managed, seeded client and worker personas need to be created through Supabase's identity system, not just inserted as database rows, or they can't sign in at all.
State machine edge cases. Once a worker checks in successfully, that gig is marked complete, so we couldn't demo a successful check-in and a missed-timeout SOS on the same gig. We designed our demo flow around two separate gigs rather than treating it as a bug, since the underlying logic was correct.

What we learned

Trust isn't one-directional in this market, clients and workers each carry real risk, and a safety product that only solves one side's problem leaves the other exposed. We also learned that the hardest part of a safety-critical system is the plumbing underneath it, not the AI: making sure a login returns a usable token, making sure seeded test accounts authenticate the same way real ones will, making sure state transitions can't fire twice. And we learned to build graceful degradation into the risk pipeline from day one — when AI classification fails, the system should still make a safe, defensible call using deterministic rules.

What's next

Community pilots with local gig-worker associations and unions, expanding USSD menus beyond English and Swahili, and deeper integrations that let gig platforms embed our safety checks directly.