01
Overview
Project name
Pebla Admin
KYB review to programme approval — with Pebla-owned commercial truth
One-line description
An internal web console for Pebla’s team to review merchant KYB, configure programme economics, approve programmes, and operate wallets, risk, and audit.
My role
Timeline
Category
Platforms
Tech stack
02
The Problem
Pebla ops cannot scale loyalty if merchant onboarding is email threads and spreadsheets. Reviewers need one place to: - Triage Partial and Full KYB applications - Set programme economics Pebla owns (AOV, points, tier thresholds, locations with MoMo/payment codes) - Approve merchants into Full KYB with an auditable trail - Later manage programmes, wallets, risk alerts, users, and reports Without a dedicated console, vendors wait blindly and Pebla cannot enforce consistent commercial terms across merchants.
03
The Solution
I built Pebla Admin as a role-aware operations product separate from the Vendor Portal (own shell, auth, and permissions; shared design tokens). Core loop for KYB: 1. Application lands in the review queue (from Vendor via local bridge or seed) 2. Ops configure Pebla programme terms - economics, tier spend + points thresholds, and per-location contact / MoMo / payment reference 3. Submit approval stamps agreed terms and unlocks Vendor Full KYB 4. Merchant profile remains the long-term home for KYB, commercial, programme, wallet, risk, notes, and audit Beyond KYB, the console covers programmes, wallets/top-ups, risk cases, platform users, reports, notifications, and ⌘K global search - all demonstrated with Rwanda-focused seed data.
04
Key Features
Merchant applications queue
Split review workspace for Partial and Full KYB triage.
Programme economics config
AOV, points per RWF 1,000, and Bronze / Silver / Gold spend & points thresholds set by Pebla ops.
Unified store locations
Each location carries contact person, phone, MoMo collection code, and payment reference.
Approve / request changes / reject
Flows with reasons and audit events so KYB decisions stay reviewable.
Role simulation & permission gates
Super Admin, Merchant Ops, Compliance, Finance, Risk, Support, Reporting - with PermissionGate on nav and sensitive actions, not button-hiding alone.
Programme review workspace
Tiers, rewards, and commercial maker-checker pattern for programme changes.
Wallets & risk (demo)
Top-up verification, low-balance, reconciliation views, plus risk alerts, investigations, and watchlist.
Audit, users & Dev Tools
Append-only audit log UI, platform user invite / role / suspend, Dev Tools to seed/reset/simulate events, and date-filtered dashboard metrics and charts.
05
Technical Implementation
Architecture
App at apps/admin with an /admin base path. Feature modules for review, programmes, wallets, risk, and platform. Shared types and labels from @pebla/domain; chrome from @pebla/ui. Zustand stores persist session, merchant review, programme review, wallet, risk, and platform state.
Backend
Frontend-first. A local file-backed HTTP bridge under Admin syncs Partial KYB, application status, and Full KYB approval with Vendor through a configurable API base URL. Bridge data stays local and gitignored. CORS allows local and private LAN origins for device testing.
Frontend
App Router pages, form-heavy review flows (RHF + Zod), tables, charts, command palette search, and PermissionGate for capability checks. Maker-checker for commercial term changes modelled in local state.
Database
Not production-backed. Seed generates many Rwanda merchants/applications with RWF and local phone formats. Bridge JSON is a transitional stand-in for a real applications store.
APIs / Integrations
Bridge routes for applications list/patch, approve-for-full-KYB, vendor KYB status. @pebla/api prepared for future BFF mapping (documented). Simulated email outbox on approval (preview UI; no real mailer).
Infrastructure
Aimed at admin.pebla.app as a separate deploy from Vendor. Locally, Admin runs alongside Vendor for end-to-end KYB demos.
06
Challenges & Solutions
Two products, one KYB journey
Built a thin Admin bridge + polling so Vendor submit → Admin configure/approve → Vendor unlock works without a full backend - while documenting the real BFF map for later.
Pebla must set tiers, not leave blanks
Extended agreed programme terms with editable spend and points breakpoints in the Partial KYB config form, then surfaced them read-only on Vendor commercial terms and locked them in Vendor loyalty setup.
Locations and codes were conceptually split
Merged into one location card model so ops cannot approve a merchant with orphan MoMo codes or missing branch contacts.
Permissions as product behaviour
Role matrix + PermissionGate and reason-required modals so sensitive ops actions stay demonstrable and reviewable even in demo mode.
CORS for Network URL demos
Expanded bridge CORS beyond loopback so Vendor on a LAN IP could still talk to Admin during device testing.
07
Results
Ops can configure and lock Pebla programme terms before Full KYB unlock. Live Partial KYB sync across Vendor and Admin via the local bridge. Multi-role console covering KYB to programmes, wallets, risk, audit, and users. Shared design system keeps Admin and Vendor visually coherent as one Pebla platform.
08
What I Learned
- 1.Internal tools need product craft too - queues, reasons, and maker-checker patterns matter as much as merchant UX.
- 2.Own the commercial source of truth in ops - if Pebla sets AOV and tiers, the Admin form must capture them, not derive them silently.
- 3.Transitional bridges beat fake "connected" UIs - a small HTTP seam teaches real failure modes (CORS, polling, approval stamps) early.
- 4.Permissions should be capability-based - role switches that only hide buttons train the wrong habits for production.
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