Xervices

The Idea

Xervices came to us with more than an idea, they had a precise read on what trust actually requires in a market where strangers do skilled work inside someone's home: a location-based marketplace connecting customers with vetted, independent professionals — plumbers, electricians, carpenters, and other artisans — where payment security and identity verification aren't nice-to-haves, they're the entire value proposition.

The Problem

The product couldn't just be an app, it had to be a system: real-time job matching and bidding, escrow-based payments, live chat, dispute resolution, and KYC identity verification against BVN and NIN records, spread across a customer-facing app, a completely separate professional-facing app with its own onboarding and wallet, and an internal admin console for the operations team. Four independent codebases, two platforms, all needing to agree on the same state in real time.

Scope Alignment

We scoped the engagement around the four systems Xervices actually needed to launch with, nothing speculative:

Key Documents

Given the compliance and real-time requirements, discovery produced three documents before a line of code was written:

• A system architecture brief — mapping how four codebases would share state in real time
• A KYC and compliance brief — covering BVN and NIN verification requirements for onboarding professionals
• A scoped build plan — sequencing which systems needed to ship first for a working end-to-end loop

System Architecture

With four codebases needing to agree on the same real-time state, the backend had to be the single source of truth every client trusted blindly:

• NestJS + PostgreSQL — the core API and relational data model for artisans, bookings, payments, and disputes
• Redis + Bull — background job queues handling matching, notifications, and anything that couldn't block a request
• Socket.IO — real-time events powering live job bidding, chat, and artisan location tracking
• Two React Native apps (Expo, New Architecture) and a React/Vite admin console, all built against the same backend contracts

Wireframes & UX Flows

The flows we mapped first were the ones trust actually depends on, not the ones that are easiest to design:

• Live tracking — a customer watching their artisan's real-time location and ETA, with call and message options
• Job bidding — a customer reviewing multiple artisan offers side by side, with the option to counter or accept
• Service discovery — browsing categories like plumbing, electrical, and cleaning, and posting a job in a few taps

The Lean Plan

With four codebases in scope, the lean plan was about sequencing, not cutting:

• 1Ship the backend and customer app first, validating the core booking and matching loop
• 2Bring the professional app online next, enabling real two-sided matching
• 3Layer in the admin console last, once there was real operational data for the ops team to manage

Success Story

Xervices shipped as four coordinated codebases built on one real-time backend: a customer app, a professional app, an admin console, and the API tying them together. The platform now runs live bookings across multiple service categories, with artisans verified against BVN and NIN before they're ever allowed to accept a job.