01
Overview
Project name
Pebla Vendor Portal
From KYB to live loyalty — without the opaque ops grind
One-line description
A merchant-facing web app for onboarding onto Pebla loyalty, configuring programmes, and running day-to-day loyalty operations in Rwanda (RWF).
My role
Timeline
Category
Platforms
Tech stack
02
The Problem
Restaurants, salons, and other merchants in Rwanda need a clear path from "I want loyalty" to a live programme - without opaque paperwork or a blank admin console. They needed to: - Prove business identity (Partial KYB → Full KYB) - Accept Pebla commercial terms they did not invent themselves - Configure card design, Bronze / Silver / Gold rewards, enrolment fields, team, and wallet funding - Operate customers, outreach, insights, and wallet once live Existing tools were either too generic, not localised (currency, phone, MoMo), or forced merchants through ops-heavy processes with little product guidance.
03
The Solution
I built the Vendor Portal as a guided product surface: 1. Self-serve Partial KYB → application status while Pebla reviews 2. Full KYB after approval, with Partial details locked so merchants cannot silently rewrite what Pebla already verified 3. Commercial terms showing Pebla-set economics (AOV, points, tier thresholds, per-location MoMo codes) as read-only 4. Programme setup - card designer, loyalty tiers/rewards, customer fields, team, wallet 5. Live dashboard - customers, outreach, insights, history, locations, settings The app is frontend-first today (Zustand + seeds) with a clear API seam (@pebla/api) and a local Admin bridge so Partial KYB approval can feel live across both products before a production backend lands.
04
Key Features
Multi-step KYB onboarding
Sign-up → requirements → status → Full KYB → commercial terms → programme steps.
Locked Partial KYB carry-over
Identity and contact fields verified in Partial KYB stay locked on Full KYB so merchants cannot silently rewrite what Pebla already checked.
Pebla-agreed commercial terms
Read-only panel for fee wording, AOV, points, tier spend + points thresholds, and locations with contact, MoMo, and payment reference.
Loyalty card designer
Bronze / Silver / Gold preview for merchant programme creative.
Tier & rewards editor
Pebla thresholds stay locked; merchants configure the rewards customers actually receive.
Customer list & detail
Search, filters, sorting, and customer detail for day-to-day operations.
Outreach compose & points allocation
Lock-screen style message preview and points allocation to filtered recipients.
Wallet, insights & team access
Top-ups, history, date-ranged insight charts, and role-aware demo roles (Admin, Finance, Cashier, Waiter). Shared Pebla design system with light/dark, UK English copy, and RWF formatting.
05
Technical Implementation
Architecture
Monorepo app at apps/vendor, base path /vendor. Routes split into public, onboarding, and dashboard groups. Domain types live in @pebla/domain; UI primitives in @pebla/ui. State is organised into Zustand stores (session/profile, onboarding drafts, programme data) with localStorage persistence for demo continuity.
Backend
No production backend in this surface yet. Forms and actions mutate local stores and (for Partial KYB) POST/GET a transitional Admin HTTP bridge so review and approval sync across ports.
Frontend
Next.js App Router pages compose feature modules. Forms use React Hook Form + Zod. Tables use a shared DataTable with sortable headers. Charts via Recharts. Auth/onboarding shells shared from @pebla/ui.
Database
Not wired in the Vendor app. Seed data models realistic Rwanda merchants, locations, customers, tiers, wallet ledgers, and audit events for UX validation.
APIs / Integrations
@pebla/api route map ready for auth, KYB, programme, wallet, and OTP. Local bridge connects Vendor Partial KYB submissions to Admin approval. Simulated: document upload, OTP, MoMo funding, outreach delivery.
Infrastructure
Designed for independent deploy (e.g. vendors.pebla.app). Local development uses a Turborepo-style workspace with a dedicated Vendor app.
06
Challenges & Solutions
Guided KYB without a real compliance backend
Modelled merchant status as an explicit state machine and used Demo Tools + the Admin bridge so ops and merchants could walk the same journey end-to-end.
Pebla-owned vs merchant-owned config
Commercial economics and tier thresholds are Pebla-set and shown read-only; merchants only edit what they should (rewards, creative, team). Locked fields still submit correctly via getValues() / identity merge.
Locations vs global codes confusion
Redesigned Pebla config so each store location carries its own contact, MoMo code, and payment reference - then mirrored that structure read-only on commercial terms.
Typing animation noise in forms
Removed SmoothInput platform-wide so KYB and ops forms use native inputs.
07
Results
Shipped a complete Vendor onboarding → live panel path with Rwanda-localised demo seed. Cross-app Partial KYB approval loop working against the Admin bridge. Clear separation of Pebla configuration vs merchant configuration in commercial terms and loyalty setup. Shared UI kit reused by Admin, keeping both products visually consistent.
08
What I Learned
- 1.Status-driven UX beats long forms - merchants understand progress when the UI mirrors real approval gates.
- 2.Read-only commercial truth reduces disputes - showing Pebla-set numbers early prevents re-negotiation inside programme setup.
- 3.Frontend-first with typed seams (domain + api) lets product move fast without painting into a corner for backend plug-in.
- 4.Localisation is product, not polish - RWF, MoMo codes, and UK English spelling change trust for this market.
09
Links
LET'S WORKTOGETHER
I design and ship production-ready systems at the intersection of cloud infrastructure, full-stack engineering, and human-centred product thinking.
Send email · kuzagbechristopher@gmail.com