Zewerk
In DevelopmentSolo Developer · Full-Stack·2026 – Present
A marketplace connecting blue-collar workers with clients across Nigeria.
Overview
Zewerk is a blue-collar worker marketplace for the Nigerian market — connecting artisans, cleaners, drivers, and other skilled workers with clients who need them. I'm designing and building the entire platform solo: frontend, backend, payments, real-time features, and infrastructure.
The Problem
Nigeria has millions of skilled informal workers with no reliable digital platform to find work, get paid safely, or build a reputation. Existing solutions are either too generic, not localised, or don't solve the trust problem between worker and client. Workers get hired once and users go around the platform directly — killing the business model. Zewerk is built to solve all of this.
My Role
Solo developer and product owner. I own every layer — product decisions, system architecture, frontend, backend, DevOps, and payment design.
Technical Decisions
Next.js App Router (not plain React)
Built-in SSR, file-based routing, and performance optimisation are critical for users on lower-bandwidth Nigerian networks. App Router also makes it easier to separate server and client components cleanly, reducing unnecessary JavaScript sent to the browser.
PostgreSQL + Prisma (not MongoDB)
The relational nature of bookings, payments, user roles, and reviews demanded structured data with enforced relationships. A booking has a worker, a client, a service, a payment, and a status — MongoDB's flexible schema would have introduced inconsistency risk at every join. Prisma gives me type-safe queries and schema migrations without raw SQL.
Redis
Used for session caching and background job queuing. Keeps the API responsive under load without hitting PostgreSQL on every authenticated request.
Paystack Escrow (not direct transfers)
Direct transfers create a trust gap — clients fear workers won't deliver, workers fear clients won't pay. Escrow holds funds from the client at booking and only releases to the worker when the job is confirmed complete. This is the core trust mechanism that makes the marketplace viable.
Socket.io (real-time layer)
Workers and clients need live job status updates — 'Worker on the way,' 'Job started,' 'Awaiting confirmation.' Polling would be too slow and expensive. Socket.io events keep both sides in sync without repeated API calls.
Termii SMS API (not email OTP)
Nigerian users are significantly more reachable via SMS than email for verification flows. Termii is the most reliable Nigerian SMS provider with a developer-friendly API.
Challenges
Strict TypeScript mode
Enabling strict TypeScript across the entire backend forced me to rethink how I handle error states. I stopped using `any` as an escape hatch and built proper typed error boundaries — a try/catch pattern where every catch block explicitly types the error before using it. This was painful at first but made the codebase dramatically more reliable.
Escrow payment state machine
Designing the Paystack escrow flow required mapping booking states to payment events: pending → active → in_progress → completed → released. Each state transition triggers different Paystack API calls. Getting this wrong could mean money being released early or stuck permanently — so I drew out the full state machine before writing a single line of payment code.
Disintermediation prevention
A known marketplace risk: once a worker and client meet, they exchange numbers and bypass the platform for the next job. My solution combines in-app messaging to keep communication on-platform, payment protection messaging that explains why escrow benefits both sides, and a reputation system where workers with strong platform ratings earn trust they'd lose by leaving.
Multi-step auth flow
Building JWT auth with plans for OAuth required separating concerns properly. I built auth as a standalone controller with its own router so adding OAuth providers later doesn't touch core user logic.
Results
Core architecture established. Authentication, worker profiles, and booking flow are functional. Escrow payment integration and real-time notifications are in active development. Pre-launch.
Retrospective
I'd validate the core marketplace assumption with a simpler, manual MVP before building the escrow system. Talking to five actual artisans first would have shaped several product decisions earlier. I'd also start the Socket.io layer from day one rather than retrofitting it — real-time needs influenced the API design more than I anticipated.