Build Market — Compliance-First Construction & Real Estate Marketplace for Kenya

Architecture case study · event-driven backend, non-custodial milestone escrow, built to survive unreliable infrastructure and strict regulation

Field Detail
Role Sole architect and engineer: product design, backend, frontend, infrastructure, and compliance modeling
Timeline 2025 – present · last updated October 2026
Status Live at buildmarket.app <!-- AUTHOR: state the real stage (pilot / beta / launched) and any usage numbers; reviewers always ask -->
Core stack TypeScript · Next.js on Cloudflare Workers · Node.js 24 · PostgreSQL + Prisma · NATS JetStream · BullMQ · M-Pesa Daraja

The 60-Second Version

Problem. Construction in Kenya runs on offline trust: contractors are hard to verify, clients pay large deposits with no protection, and the registers that could confirm a credential live on portals that are frequently down.

Approach. Build Market is a technology intermediary, not a contractor. It verifies professionals against nine statutory boards, holds milestone payments in non-custodial bank escrow, and runs on an event-driven backend that treats external failure as the normal case.

The three hardest problems

  1. Reliability against unreliable regulators. Cache, circuit breaker, retry stream, then a human review queue, so the user journey never blocks (Section 8).
  2. Money-movement correctness. Idempotent M-Pesa flows, deterministic message IDs, and acknowledge-after-commit delivery so a crash can never double-pay (Sections 2.3, 3.1).
  3. Governance without a team. 26 ADRs enforced by static checks, since there is no second reviewer on a solo project (Sections 4, 6).

Evidence. 4 apps · 8 shared packages · 114 models · 6 JetStream streams · 26 ADRs · security drift scanner at 0 findings across 309 files.

Contents

  1. Technical architecture and stack justification
  2. Architectural deep-dives
  3. Localized Kenyan ecosystem integrations
  4. Architectural decision records
  5. Observability and operational readiness
  6. Testing, drift gates, and verification
  7. Admin overhaul and strangler-fig evolution
  8. Designing for legacy unreliability