Kaziiko is Kenya's first verified freelance marketplace. We built it. Here's the full technical story — the architecture decisions, the M-Pesa escrow system, the verification challenges, and what we'd do differently.
In late 2023, a question kept coming up in our client calls: "Where do I find a reliable Kenyan developer, designer, or digital marketer — someone I can actually trust with my money?"
The answer, at the time, was unsatisfying. LinkedIn worked if you had connections. WhatsApp groups were hit-or-miss. Upwork and Fiverr exist, but the payment friction for Kenyan clients and the distance from local context made them awkward fits.
So we built Kaziiko — a Kenyan freelance marketplace that lets businesses post digital projects, connect with verified local professionals, and pay safely through M-Pesa escrow.
This is the technical story of how we built it.
The biggest blocker in Kenyan freelancing isn't talent — it's trust. Clients have been burned by disappearing freelancers. Freelancers have been burned by clients who take the work and ghost them.
We made one foundational product decision early: escrow had to be built into the core transaction flow, not bolted on later. Every project on Kaziiko works the same way. The client deposits payment into escrow when the project starts. The freelancer gets paid when the client approves the work — or through a dispute resolution process if there's a disagreement.
This single decision shaped everything else: the UX, the M-Pesa integration, the legal structure, and the trust signals we built into every profile.
Kaziiko runs on Safaricom's Daraja API. Implementing M-Pesa escrow was the most technically demanding part of the build — not because the API is poorly documented, but because escrow adds a layer of state management that a simple payment doesn't require.
A standard M-Pesa STK Push collects money and confirms it. Escrow requires us to:
1. Receive the deposit and record it as "held" (not yet disbursed) 2. Track the project state — in progress, submitted, approved, disputed 3. Trigger disbursement to the freelancer's M-Pesa on approval 4. Handle partial releases for milestone-based projects 5. Process refunds to the client if a project is cancelled before work starts
We built a state machine for each transaction that tracks every step, with webhook handlers for Daraja callbacks and idempotency keys to prevent double-processing if a callback fires twice (which happens).
One detail that caught us: Daraja's B2C (business to customer) API for disbursements has different rate limits and error codes than the STK Push API. You need to handle each set of errors separately and build queue-based retry logic for failed disbursements. We use a Redis-backed queue with exponential back-off.
Anyone can create a profile and claim expertise. The verification system is what makes Kaziiko different from a classified ad board.
We built a three-tier verification model:
Tier 1 — Identity: National ID number verified against the IPRS (Integrated Population Registration System) via a third-party KYC provider. Every freelancer on Kaziiko has a verified Kenyan identity tied to their account.
Tier 2 — Skills: Skill assessments for core categories. A web developer takes a timed practical test. A social media manager submits a portfolio review. We built a custom assessment engine — nothing off-the-shelf fitted the local context well enough.
Tier 3 — Track record: Completed projects, client reviews, and dispute history. This is the layer that compounds over time and becomes the real signal for clients.
The UX challenge was making verification feel like progress, not bureaucracy. We designed the onboarding as a "get verified" flow with clear status indicators — each tier unlocked higher project value limits, which gave freelancers a reason to complete it.
The core platform is built on Next.js with a PostgreSQL database. We chose Next.js because we've standardised on it across our client work at Mycrea, which means the same team that builds client websites could iterate quickly on Kaziiko without a context switch.
The key architectural choices:
Build the dispute resolution system earlier. We launched with a manual dispute process — email us, we'll mediate. It worked for the first few months but didn't scale. The in-app dispute flow with evidence upload and structured timelines should have been a launch feature, not a v1.1 addition.
Invest in the mobile app sooner. Kaziiko launched as a mobile-responsive web app. The web experience works, but for freelancers who are managing multiple projects from their phones, a native app with push notifications would materially improve their workflow. We're building it now.
Don't underestimate the onboarding drop-off. We assumed that once a freelancer created an account, they'd complete verification. They didn't — not automatically. We rebuilt the onboarding sequence three times before we got to an activation rate we were happy with. The final version uses progressive prompting: complete one tier, see the unlock, get nudged toward the next.
Every product decision we made on Kaziiko reflected something specific about how Kenyans do business digitally. M-Pesa as the payment layer. WhatsApp as the notification layer. IPRS integration for identity. The .co.ke domain for local trust signals.
These aren't compromises made for a market that "isn't ready" for something more sophisticated. They're the right architecture for a market that has already solved the problems other markets haven't — mobile money, biometric identity, high smartphone penetration — in different ways.
The best digital products in Kenya are built by people who understand that context. That's what we try to build at Mycrea, and it's what we built into Kaziiko.
---
*Kaziiko is live at kaziiko.co.ke. If you're a Kenyan business looking for verified digital talent, or a freelancer looking for your next project, that's where to go.*
Tell us about your project. We'll show you what's possible.
