SusuPaa Platform
Co-founder & Lead Engineer · SusuPaa · 2025 · Shipped
GoPostgreSQLRedisMulti-tenant ArchitectureAppend-only Ledger
The problem
Susu collectors, savings cooperatives, and microfinance institutions were running group savings, passbooks, and loans through WhatsApp messages, paper ledgers, and phone calls. Any system replacing that had to be the single source of truth for money it never held: every contribution, payout, and repayment provable after the fact, no double-credits under concurrent operations, and strict isolation between hundreds of independent organizations sharing one deployment.
SusuPaa is a multi-tenant platform for Ghana's informal savings sector: susu collectors, savings cooperatives, and microfinance institutions. Each organization runs its own groups, savings plans, loans, and accounting on a shared deployment, and every money movement has to be provable later. I co-founded the company and led the platform from the first commit.
The core is an append-only ledger I designed and operate. Entries are never updated or deleted; balances are derived from the entry history, so any balance can be reproduced from the record that produced it. That is what gives the system its consistency guarantees: a contribution, a payout, and the group balance they affect are written as one unit or not at all, and there is no path that mutates a balance without a corresponding entry.
Concurrency was the second design problem. Settlement jobs run concurrently, and the failure mode in this kind of system is the same everywhere: a job processed twice credits someone twice. Jobs are claimed atomically from a Postgres-backed queue, so each payment or payout is processed exactly once under load, with no double-crediting and no orphaned settlements.
Performance came next. p99 API latency was 1.6 seconds. Refactoring PostgreSQL query plans and adding a tiered Redis caching strategy brought it to 500ms.
Operating it means being able to see it and recover it. I stood up the observability stack (Prometheus metrics, Grafana dashboards, Loki log aggregation) and PostgreSQL WAL archiving to S3 for point-in-time recovery, so a bad deploy or a corrupted write is recoverable to the second rather than to the last nightly dump. The platform has processed over $1M in transactions.
On top of the ledger sit the product modules: group susu from the first slot to the final payout, savings plans and digitised passbooks, lending from application to write-off with real-time portfolio-at-risk and automated provisioning, and accounting with a trial balance by account. Money movements are under dual control, staff roles are separated so no one person can do everything, and field payments can be recorded offline and synced when connectivity returns. Loan reporting maps to Bank of Ghana categories and GCSCA lines.
Contributions and payouts move over mobile money on all three Ghanaian networks and bank transfers through Moolre, Hubtel, Paystack, and LibertePay; user funds never sit with SusuPaa. A read-only assistant, SusuPal, answers questions over an organization's own data and cannot modify anything.
Beyond the code, I direct the technical roadmap, lead code reviews, and run sprint planning for a remote team of five engineers.
Coverage: Tech Labari, MyJoyOnline.
What I'd do differently
Starting with event sourcing from day one rather than retrofitting it later. Our transaction ledger needed audit trails that we had to rebuild after launch — designing the data model around immutable events from the start would have saved us two weeks of migration work. I'd also invest earlier in contract testing between services; we had integration bugs that only surfaced in staging because our unit tests mocked too aggressively.

