Kwikpik Super-app

The problem

Kwikpik started as a delivery app. Then it grew a wallet. Then bill payments, transfers, payment automations. Each feature was bolted onto one navigation tree and one Redux store, so every release touched everything, and every new product team had to understand all of it.

What I built

Over three major versions I built and evolved the customer app — real-time ordering, live rider tracking over Socket.IO, in-app chat — and then restructured it into a mini-app shell.

• An AppRegistry. Each mini-app (dispatch, finance, bill payment) is a self-contained folder that exports a config and registers itself. The shell lazy-loads them on boot.
• Runtime reducer injection. Core slices (auth, user, UI) are always there; a mini-app's slices are registered when it loads, after persisted state rehydrates. Nothing in the core imports a mini-app.
• An EventBus for the few things that do cross boundaries — wallet:updated after a transfer, for instance — instead of mini-apps reaching into each other's state.
• Per-mini-app navigation. Each one owns its screen list. A config that tries to be both a root navigator and a tab is rejected at registration, not discovered in QA.
• A shared kwikpik-ui package — tokens, typography, components — in a pnpm monorepo shared with the rider app.

Money movement

I built the wallet's money-movement suite and the payment automations on top of it: recurring bills, scheduled transfers, and bulk multi-recipient transfers with per-recipient status. Later I migrated the wallet from Flutterwave fiat rails to a custom Hedera Hashgraph wallet — the hardest kind of migration, because nobody notices when it works.

The rider app

The companion rider app handles last-mile delivery, including for Temu and other e-commerce platforms: accepting jobs, live location, wallet and KYC. I own its over-the-air releases and production stability — which mostly means saying no to shipping native changes through an OTA channel.

Outcome

• New products ship as mini-apps without touching core navigation or the root store.
• Two apps share one component library, so a design change is one PR, not two.
• Three generations of the app, each one shipped without a rewrite freeze.