Client work · Consumer credit
Beacon
Making a credit report people could understand
Beacon was a Nigerian consumer credit product. Users verified their identity with their BVN, linked their bank accounts through open banking, and received a personal financial and credit report. Lenders received pre-qualified leads, which they used in their own underwriting. Revenue came from tokens users bought to generate and refresh reports, and from those leads.
Many users had no idea whether they were creditworthy, and raw balances, inflows and open loans did not help them find out. Users who did not understand their report did not come back to refresh it and did not go on to apply for credit. That hurt users and both revenue streams at once: fewer refreshes meant fewer token purchases, and fewer applications meant fewer leads.
- Sector
- Consumer credit
- Stack
- Nuxt.js · Vue.js · TypeScript · Pinia · Vuetify · TailwindCSS · Chart.js · D3.js · GSAP
Approach
- 01
A story, not a dashboard
A dashboard puts every figure on one screen, which is a wall of numbers to someone unsure where they stand. I built the report as a slide-style experience, closer to Spotify Wrapped than to a bank statement, so users moved through their finances one idea at a time.
- 02
A grade instead of a raw score
A raw score means little without a reference point, and most users had none. I presented the rating as a gauge graded F to A, with a plain-language label on each grade, because a letter grade is understood instantly in a way a number is not.
- 03
Plain-language sections
Accounts, income and outstanding loans each got their own plain-language view. Outstanding loans were grouped by lender under "See who you're owing", so a user's whole debt picture sat in one place.
- 04
An action plan as the reason to return
A grade says where you stand, not what to do next. Each report ended with concrete steps for improving it, covering debt profile, spending habits and cash-flow consistency. That gave users a reason to come back and refresh the report, which is what the token model depended on.
- 05
Making a private report shareable
A financial report is private by default, so it never spreads. I added achievement badges, such as "Repayment Ninja" and "Credit Worthy", that users could download or share as images with a QR code. That turned the report into something users posted, and each share doubled as organic acquisition.
- 06
The flows that fed the report
I also built the flows behind it: BVN verification by OTP, open-banking account linking that picked up newly linked accounts automatically, token purchases for refreshes, and the lead form that passed qualified users to lenders. I owned the frontend end to end and worked with the backend team on the API contracts.
Outcomes
- Users got a report they could understand: a grade, a few plain sections and a clear next step, in place of a page of raw figures.
- The action plan and badges gave users reasons to return and to share, supporting token revenue through refreshes and bringing new users in through shared badges.
- Lenders got a cleaner lead pipeline: users with verified identity, cash-flow data and a stated loan purpose, who understood where they stood before applying.
More work
- Payments infrastructure
Meridian
Improving transaction success rate
Card and virtual account payments were failing often enough to hurt merchants and customers. Retry-aware routing across providers, plus sockets in place of status polling, moved the success rate from the mid-to-high 70s to 94–98%.
Payment Routing · Retry-Aware Routing · Real-Time Systems · Product Strategy
- Consumer discovery
Atlas
Resolving a structural unit economics risk
A core feature ran on a pay-per-call third-party API. Modeled forward against projected growth, cost-to-serve would scale with adoption. A first-party data layer became the default experience, and the paid dependency was repositioned as a monetized premium tier.
Unit Economics · Data Strategy · Cost-to-Serve · Product Architecture