Case Study · Kharon Pay
Why We Sunset a Starknet-Based Fintech Product
Product strategy, a market-risk flag raised early, and the deliberate call to wind down when product-market fit didn't land in the window we were given.
- Role
- Product Manager & Frontend Engineer
- Period
- Aug 2024 – Jan 2026
- Stack
- Next.js · React · TypeScript
- Outcome
- Deliberate wind-down, January 2026
Problem
Africans moving money between local currency and crypto face real friction: limited on/off-ramps, poor UX on the ones that exist, and infrastructure that's rarely built with African payment behavior in mind. Kharon Pay set out to fix that with a Starknet-based fiat-crypto on/off-ramp.
My Role
I owned product strategy and roadmap, and built the production frontend in Next.js/React, working directly with backend engineers to define API contracts and align on fiat-crypto conversion logic. The build covered the full on/off-ramp surface: verification-code sign-in, a USDC/USDT wallet, stablecoin-to-Naira swaps with the rate shown at confirmation, add-and-select bank accounts, email withdrawal receipts, and settlement a user could verify on Starknet's block explorer. The product decision to build exclusively on Starknet wasn't mine alone; it was a team call.
What Happened
I raised concerns early that building solely on Starknet was a risk: token liquidity and usage in our target Nigeria/Africa market were meaningfully lower than on chains like Base or Solana. The team proceeded anyway, given the available Starknet education grant and genuine technical interest in the ecosystem.
We never reached a public launch. Internal beta-testing rounds surfaced real, recurring UX issues in payment flow, modal design, and mobile responsiveness, and we fed fixes back into the frontend. But scaling the product required liquidity we didn't have. In December 2025, Starknet awarded a $5K grant specifically to validate product-market fit, with a conditional $25K liquidity grant if we could demonstrate it. We had roughly six weeks, from the first week of December to mid-January, to show PMF.
The payment flow, working
When there's a real tension between what the team is excited to build with and what the target market actually uses, that tension needs a harder answer before writing code, not after.
Outcome
We couldn't demonstrate PMF in that window. Rather than keep the product alive while continuing to pay for a microservices backend with no liquidity funding behind it, we made the call to sunset Kharon Pay in January 2026.
What I'd Do Differently
The early market-risk flag on Starknet's liquidity in our target region turned out to matter more than the team weighed it at the time. The lesson I'm carrying forward: when there's a real tension between what the team is excited to build with and what the target market actually uses, that tension needs a harder answer before writing code, not after. I'd also push for a defined PMF gate and timeline from day one, not just when a grant forces the question.