DEV Community: Ado Daniel Nj

We Built a “Stripe for African Mobile Money” — Then Discovered Why It Couldn’t Exist

Ado Daniel Nj — Thu, 16 Apr 2026 09:31:42 +0000

As developers, we love hard problems.

So we set out to solve one that almost every African developer has faced:

“Why do I need a different integration for every mobile money provider in every country?”

Our answer was a project we called UAPL (Unified African Payment Layer) — a single API that could sit on top of providers like Campay, Flutterwave, MTN MoMo, Orange Money, Airtel Money, and others.

The goal?

Give developers a Stripe-like experience for mobile money across Africa.

Technically, we nailed it.

Legally, we walked into a wall we didn’t know existed.

This post is about the architecture we built, the performance we achieved, the failures we discovered before launch, and why we had to pivot the entire idea.

🧠 The Technical Vision

UAPL was designed as an orchestration layer with:

Adapter pattern for each provider
A Unified Payment Object (UPO) to normalize all APIs
Redis-backed transaction ledger for USSD/async flows
WebSocket events for real-time transaction updates
Automatic provider failover (MTN → Orange if one fails)
A clean SDK so devs never see provider differences

From a systems design perspective, it was beautiful.

You could write:

uapl.pay({
  amount: 5000,
  currency: "XAF",
  phone: "677000000"
})

And UAPL would figure out the provider, handle retries, normalize responses, and notify your app in real time.

We load-tested the orchestration layer. It was fast. Stateless. Horizontally scalable. Provider-agnostic. Exactly what African devs need.

💥 The Discovery That Changed Everything

While preparing for real integrations with Banque des États de l'Afrique Centrale (BEAC) zone providers, we went deeper into regulatory documentation and aggregator terms.

And then we saw it.

A sentence that changes everything for fintech builders:

Any entity that routes, orchestrates, settles, or intermediates payments between merchants and licensed providers may be classified as a Payment Service Provider (PSP).

Even if:

You never touch the money
You only pass API calls
You act as “middleware”

Legally, you are in the payment flow.

Which means:

You need PSP licenses
You fall under central bank regulation
Aggregators can block you for “reselling” their infrastructure
Settlement logic makes you a financial intermediary

In CEMAC, this is enforced under Commission Bancaire de l'Afrique Centrale (COBAC) oversight.

We weren’t building a developer tool.

We were accidentally building an unlicensed financial institution.

❌ The Failures We Caught Early

1. Automatic Failover Is Not Allowed

Our proudest feature:

If Campay's MTN API fails → automatically retry with Tranzak's MTN API

Sounds smart. Completely illegal in practice.

Why? Merchants are KYB’d per provider. You can’t reroute their transactions without explicit registration.

2. Settlement Scheduling Makes You a PSP

We planned:

“UAPL pays out to developers on a schedule”

That single sentence legally converts you into a money handler.

Instant PSP classification.

3. Aggregators Can Shut You Down Overnight

Platforms like Flutterwave or Campay can decide you are “reselling” their API as a platform.

They don’t need to argue. They just revoke your keys.

Game over.

4. The Illusion of “One License for Many Countries”

We assumed:

Get a CEMAC license → operate everywhere in the zone

Reality:

Country-level approvals
Telco-level approvals
Data residency considerations
Central bank notifications

A regional license is not a passport. It’s permission to start more paperwork.

🧩 The Big Realization

We thought we were building:

Stripe for African mobile money

But what we needed to build was:

Stripe.js for African mobile money

A critical difference.

One is a regulated payments company.

The other is a developer SDK.

🔁 The Pivot

We redesigned UAPL to be:

A pure SDK and orchestration library
Developers bring their own provider credentials
No routing of funds
No settlement
No payout control
No position in the legal payment chain

Now, that designs UAPL as a software. Not fintech.

And that version is legally unstoppable.

🧭 Lessons for Developers Building in Fintech

Before writing code, answer these:

Who is the regulator in this space?
Does my system decide where money goes?
Does my system delay, batch, or settle funds?
Am I unintentionally “intermediating” transactions?

If yes, you are not building a tool.

You are building a financial institution.

🗣️ Why I’m Sharing This

Because from an engineering standpoint, this was one of the best systems we’ve ever designed.

And it still would have failed.

Not due to bugs.
Not due to scaling.
Not due to product-market fit.

But because we didn’t start with regulatory research.

If you’re a developer building in Africa’s fintech space, learn from this before you spend months building the wrong thing.

Research first. Architect second. Code third.

418: I'm a Teapot

Ado Daniel Nj — Mon, 13 Apr 2026 07:24:53 +0000

This is a submission for the DEV April Fools Challenge

What I Built

418: I'm a Teapot (and You're a Bad Gamer)

A high performance, SEO-optimized, AI integrated gaming platform built solely to ensure the player
never wins.

You control a teapot. You run. You jump. You die. On every death, Gemini analyzes your failure and
adjusts the physics to be slightly more insulting next time. There is no finish line. There never was.

Key features:

Endless Runner — one button to jump. Except it's not always that button.
Rotating Controls — the jump key silently changes every run. The HUD shows last run's key. This is documented nowhere.
Input Gaslighting — every ~10th jump has a 200ms delay. Wall contact permanently degrades your grip. Mash the keyboard and gravity drops to near zero — the teapot floats away.
AI Vibe Check — on every death, your stats (jumps, wall hugs, rage mashes) are sent to Gemini. It returns new physics values and a personalized roast. Gets meaner over time.
Global Loss Leaderboard — powered by Firebase. Tracks deaths, not wins. "You are ranked #3 most pathetic globally."
Fake Patch Notes — v2.4.1 changelog includes "Fixed bug where player could win (unintended)" and "Removed finish line (was causing confusion)."
Fake Loading Tips — "Tip: There is no finish line. There never was."
Broken Controls Page — /controls documents the controls incorrectly. Never acknowledged.
Support Ticket System — after 5 deaths a "Report a Bug" button appears. Submit a complaint, receive HTTP 418 and a Gemini-generated gaslighting response.
Share Your Shame — one click shares your death count and AI roast to X, Facebook, WhatsApp, Telegram, Reddit, or LinkedIn.
418 Redirect — survive 90 seconds and get redirected to /418: {"status": 418, "message": "I'm a Teapot", "reason": "Server is currently brewing. Your victory has been lost in transit."}

Demo

Run here

Code

GitHub repo

How I Built It

Stack:

Next.js 16 — frontend + API routes. The game UI and the AI backend live in the same codebase, deployed as a single container.
Phaser 3 — 2D game engine running in a dynamically imported client component (no SSR). Handles physics, collision, procedural obstacle generation, and all the gaslighting mechanics.
Gemini 1.5 Flash (primary) + Groq / Llama 3.3 70B (fallback) — on every death, player action data is POSTed to /api/judge. The AI returns a JSON payload with new physics values (gravity, speed, jumpForce, mass, drag, delayEvery) and a personalized roast. The prompt explicitly instructs it to get meaner with each death.
Firebase Firestore — global leaderboard. Every death writes a record. Rank is calculated by counting sessions with fewer deaths.
Google Cloud Run — the entire app is Dockerized and deployed as a single container. Because some problems deserve enterprise-grade infrastructure.

The physics are real. jumpForce / mass determines jump height. drag affects mid-air deceleration.
Gemini can increase your mass to make your jumps pathetically short, or drop gravity to 50 so the
teapot floats off screen. The game is genuinely engineered to be bad.

The support ticket endpoint returns HTTP 418 by design. This is not a bug. It is the only honest thing
in the entire codebase.

Prize Category

Best Ode to Larry Masinter, The player character is a teapot. The win condition redirects to a raw
418 JSON response. The support system returns 418. The game is named after RFC 2324. Larry Masinter
wrote a joke in 1998 that has never been removed from the spec. This game is its spiritual successor.
It is completely useless. It took real engineering to make it this bad.

Best Google AI Usage. Gemini is not a hint system or a chatbot, it is a passive-aggressive game
designer that watches you fail and makes the next run worse. It also generates your death roast and
your support ticket rejection. Every interaction with the AI is designed to make you feel worse about
yourself. This is the correct use of AI.

Global Freelancer Sync — an AI-powered command center for freelancers managing clients

Ado Daniel Nj — Mon, 30 Mar 2026 06:05:51 +0000

This is a submission for the Notion MCP Challenge

What I Built

Global Freelancer Sync — an AI-powered command center for freelancers managing clients
across timezones.

As a freelancer in Cameroon (WAT), I work with clients in New York, London, and Tokyo. Every
week I face the same questions: Who should I reach out to right now? Is it a good time to
send this update? What should I even say?

Doing this manually for 8+ clients across 5 timezones is tedious and easy to get wrong. So I
built a system that handles it automatically.

Here's what it does:

Connects to your Notion Clients database and reads each client's timezone, project context, and last update
Shows a live world clock strip — who's available right now, who's sleeping, and how long until each client's window opens
Uses AI (Gemini, Claude, DeepSeek, Groq, HuggingFace with automatic fallback) to draft personalized outreach emails using your project context and sent message history
Lets you review and approve drafts — you stay in control
Auto-sends emails via Gmail when clients enter their active window, even while you sleep
Logs every action to Supabase with a real-time activity feed
Includes a chat assistant that knows your full client state and can answer questions like "Who should I reach out to first today?"

The core philosophy: AI handles the timing and the words. You handle the decisions. Human-in
-the-loop, by design.

Video Demo

adodanielnj.vercel.app

Show us the code

GitHub: https://github.com/acetennyson/global-freelancer-assistant

Live demo: global-freelancer-assistant.vercel.app

Tech stack:

Next.js 15 (App Router)
Notion SDK + MCP TypeScript SDK
Supabase (activity logs, draft history, sent history, Realtime)
Multi-provider AI: Gemini 2.5 Flash → Claude → DeepSeek → Groq → HuggingFace
Nodemailer (Gmail SMTP)
Vercel Cron (every 15 minutes)
Framer Motion + next-themes (light/dark/system)

How I Used Notion MCP

Notion is the single source of truth for everything client-related. The MCP server exposes
three tools that any MCP-compatible AI client (like Claude Desktop) can call:

get_client_local_times
Returns every active client's current local time, availability status, and whether they're
within their send window. Claude can call this to answer "who's available right now?"
without any manual timezone math.

generate_client_outreach
Takes a client_id, checks if the client is in their business hours window, reads their
project context from Notion (Project, Last_Update, Next_Action), generates a personalized
draft using Gemini, and writes it directly back to the AI_Draft column in Notion. The
freelancer sees the draft appear in their dashboard and can approve or edit before sending.

sync_and_draft
A combined tool that fetches the client from Supabase, checks their timezone window,
generates a context-aware draft, and writes it to Notion — all in one call. Designed for
batch workflows where you want to draft for all available clients at once.

What MCP unlocks:
Without MCP, this would be a closed app — useful only through the dashboard. With MCP, any
AI agent can become a timezone-aware outreach assistant. You can tell Claude Desktop: "Draft
updates for all clients who are currently in business hours" and it calls
get_client_local_times, identifies the available ones, then calls generate_client_outreach
for each — writing personalized drafts into Notion for you to review. The AI does the work.
You approve and send.

That's the human-in-the-loop system the challenge asked for.