Remi

The problem

Cross-border payments into Africa are still priced like a luxury. A worker in Berlin sending €200 to Nairobi loses 6–9% to intermediaries, and the money takes days to arrive. Stablecoins solved the settlement problem years ago — USDC moves in seconds for cents — but holding USDC is useless if your landlord wants M-Pesa.

Remi closes that last mile: receive USDC on whatever chain the sender prefers, off-ramp to local currency in 80+ countries. The thesis is that the chain should be an implementation detail. Nobody using Remi needs to know what Solana is.

Constraints

Three constraints shaped every architecture decision:

• Low bandwidth, mid-range devices. Our median user is on a $150 Android phone, often on 3G. The app budget was a cold start under 4 seconds on that hardware, and every flow had to survive a dropped connection mid-transaction.
• Multi-chain without multi-app. Senders live on different chains — Ethereum, Base, Arbitrum, Polygon, Solana. Supporting EVM chains and Solana from one codebase means two signing models, two fee markets, and two failure vocabularies behind one UI.
• Regulatory surface. Off-ramping touches money-service regulation in every corridor. Each off-ramp partner has different KYC tiers, limits, and webhook semantics. The system had to treat compliance as a first-class state machine, not an afterthought.

Architecture

The shape is a thin client over a Go services layer, with chain complexity pushed as far from the user as possible.

• React Native client. One codebase for Android and iOS, with Android as the primary target. Heavy lifting (key derivation, transaction construction) happens in native modules; the JS thread stays free for UI. Offline-first: every mutation is a queued intent that reconciles when connectivity returns.
• Go backend. A small set of services — quoting, orchestration, ledger, webhooks — each owning its own state. Go was chosen for predictable memory under load and because a single static binary simplifies our deployment story.
• Chain abstraction layer. A Transfer is the unit of work, not a transaction. The orchestrator resolves a transfer to chain-specific legs: EVM legs go through an in-house signer service using EIP-1559 with replacement logic; Solana legs use durable nonces so a transfer survives client death between quote and submit.
• Self-hosted Supabase. Postgres, auth, and realtime — self-hosted because user financial data shouldn't transit a third party's multi-tenant infrastructure, and because regional data-residency questions get much easier when you own the box.
• Double-entry ledger. Every balance the user sees is derived from an append-only double-entry ledger, never from chain state directly. Chain reorgs, delayed finality, and partner webhook retries all reconcile against the ledger rather than mutating user-visible state.

The chain is an implementation detail. The ledger is the product.

The quoting path is the hot path: a quote aggregates chain fee estimates, partner FX rates, and liquidity in under 3 seconds at P95, then locks for 60 seconds so the user never sees a price move between confirmation and execution.

My role

I founded the product and led engineering throughout. Concretely: I designed the chain abstraction and the ledger model, wrote the Go orchestrator and the Solana signing path myself, set the React Native performance budgets, and ran security reviews on every release — the same methodology we sell at 41Swara, applied to our own product. Team of four at peak; I did the hiring.

Outcomes

• Off-ramp coverage in 80+ countries through a partner mesh with automatic failover — when one partner's corridor degrades, the orchestrator reroutes mid-transfer.
• Six chains behind one send flow, with no chain-specific UI anywhere in the app.
• P95 quote latency under 3 seconds on production traffic; cold start at 3.1s on a Tecno Spark on 3G.
• Zero ledger discrepancies since launch — every reconciliation pass has closed clean, which is the only metric a payments engineer should brag about.