Skip to content
EE
All work

Biddy

A Nigerian marketplace taken from zero to 10,000+ users

Biddy — A Nigerian marketplace taken from zero to 10,000+ users
Client
Biddy
Role
Lead founding developer
Year
Nov 2023 — Jan 2026
Status
Live

The problem

An auction-driven consumer marketplace covering electronics, fashion, vehicles, real estate and food, where sellers list, buyers check out through Paystack, and a seller tier system drives placement. Event-driven microservices behind it, and I owned architecture, frontend, backend, infrastructure and production support across roughly 1,500 commits.

Nigerian online commerce has a trust deficit at both ends: buyers can't tell a real seller from a fake listing, and sellers have no way to prove they're legitimate. Solving it needs a lot of unglamorous machinery working at once — identity, listing moderation, payments that clear locally, order tracking, returns, and a support channel — none of which is optional and none of which can be a placeholder once real money is moving.

Biddy marketplace homepage showing product categories and live listings
The homepage carries live listings across every category — electronics through to real estate.
Biddy category browse page with filters
Category browse with filtering, built to stay fast as the catalogue grew.
Biddy category index listing every product category on the marketplace
The full category index. A general marketplace lives or dies on whether people can find the one thing they came for.

How I built it

01

Payments and infrastructure chosen for where the users are

Paystack rather than Stripe, because local card and bank-transfer coverage and roughly 1.5% + ₦100 fees are what actually work for Nigerian sellers. Deployment goes GitHub Actions → a container image on GHCR → SSH deploy onto a VPS, rather than a managed platform: predictable cost in a market where margins are thin, and no per-invocation surprises during a traffic spike.

02

A separate console for the people doing moderation

Listing moderation is a different job from shopping, done by different people under different pressure, so it lives in a separate admin application on its own subdomain. Staff approve pending products to live, demote live products back to pending with a reason attached, manage accounts, and handle returns and orders. Signup is token-gated so only invited staff can register — the alternative is an admin panel one leaked password away from the catalogue.

03

Services that could fail independently

Checkout, listings, notifications and moderation don't share a failure mode, so they don't share a process. They're separate services communicating over NATS.io, which means a notification backlog doesn't stall a checkout and a moderation deploy doesn't take the catalogue down. Authentication was centralised behind Keycloak rather than reimplemented per service — one place for sessions, roles and SSO, which is also the only sane way to keep the staff console and the storefront honest about who a user is.

04

Owning production, not just the pull request

The part that changed how I work wasn't the architecture, it was being the person paged when the marketplace broke. Sentry for error tracking, Upstash Redis for rate limiting and caching, Pusher for realtime, a PWA layer for repeat mobile buyers. Every one of those went in because something failed first.

Built with

  • Next.js
  • TypeScript
  • Node.js
  • Python
  • FastAPI
  • PostgreSQL
  • Prisma
  • NATS.io
  • Keycloak
  • Paystack
  • AWS S3 + SES
  • Upstash Redis
  • Sentry
  • Docker
  • Kubernetes
  • GitHub Actions

Outcome

  • Grew past 10,000 users with millions of naira in transactions processed
  • ~1,500 commits across the marketplace and a separate token-gated admin console
  • Event-driven services over NATS.io with Keycloak SSO across the platform
  • Paystack checkout, order tracking, returns, reviews and live chat in production
  • Containerised CI/CD from GitHub Actions through GHCR to a self-managed VPS