Ohana Africa
Technologies & Architecture Stack
Overview
Ohana Africa, built for Haagbo Inc., turns the informal savings group into software. Across West and East Africa, families, churches, funeral committees, cooperatives and workplace groups have pooled money the same way for generations — by hand, on paper, on trust. The structure works. The ledger does not.
Ohana keeps the social structure and replaces the bookkeeping. A group is created, managers are appointed, contribution pools are opened, and members pay in and withdraw through mobile money. On top of that sits peer lending priced against a TrustScore built from a member's own contribution behaviour, and a savings-goal feature that lets members save towards a specific merchant purchase.
It runs in Togo, Kenya and Nigeria, in English and French, across four payment rails — TMoney, M-Pesa, Ecobank and cards — with more than 10,000 Play Store installs.
My role: Team Lead at Bixosoft. I built this alongside my team, with the team working under my supervision.
The Challenge
Most fintech assumes money belongs to a person. This one does not. The balance belongs to a group, several people can act on it, and every member has to be able to see that nothing has gone missing.
- Trust is the product. Informal savings groups run on paper ledgers and memory. Disputes about who contributed what are common, and they are corrosive — they break up the group. Transparency is not a feature here, it is the entire reason to switch.
- Balances are not personal. User wallets, group wallets, pool balances and sub-accounts all coexist, and money legitimately moves between them. Every one of those movements has to be modelled explicitly, because an ambiguous transfer is an accounting hole.
- Three markets, four rails. TMoney, M-Pesa, Ecobank and card payments each have their own confirmation semantics, their own latency and their own failure modes. A payment that is 'pending' means something different on each.
- Credit without credit history. Peer lending needs a basis for trust, but most users have no formal credit record to draw on.
- Connections drop mid-transaction. A retried withdrawal that debits twice would end the product. On these networks, retries are not an edge case — they are normal operation.
- Two languages, three regulatory environments. English and French across markets that differ in payment behaviour and in the rules governing it.
Solution & Architecture
Multi-balance model
- User wallets, group wallets, pool balances and sub-accounts modelled as distinct balance types rather than one generic account.
- An explicit transfer matrix defines which balance can move money to which — anything not on the matrix is not a valid operation.
- Every movement is attributable, which is what makes the group ledger auditable by its own members.
Transaction safety
- Withdrawal handling hardened so a retry after a dropped connection can never debit twice.
- Operations designed to be idempotent, because on these networks the client will retry.
- Offline-resilient sessions so a connection drop does not lose the user's place or their in-flight action.
Governance encoded in software
- A minimum of two managers per group, so no single person can move the group's money alone.
- Manager approval required for withdrawals, expenses and disbursements.
- Supervisors for organisational groups such as churches and cooperatives, which have a real hierarchy to respect.
Transparency by default
- Contributions and withdrawals visible to the group, which is precisely what the paper ledger failed to deliver.
- Pool balances and member contributions readable at any time without asking the treasurer.
Four rails behind one interface
- TMoney, M-Pesa, Ecobank and card payments normalised into a single payment abstraction.
- Each rail's confirmation semantics and failure modes handled explicitly rather than assumed to be equivalent.
- Adding a market means adding a rail implementation, not reworking the payment flow.
TrustScore lending
- A credit signal derived from a member's own contribution behaviour inside the platform.
- Members who save consistently become eligible for larger loans, which turns participation into creditworthiness.
- Peer lending priced against that score rather than against a formal credit record that most users do not have.
Bilingual Flutter client
- One cross-platform client for Android and iOS, fully localised in English and French.
- Published to both Google Play and the App Store from a single codebase.
Real-time support
- In-app support chat over WebSockets, including voice messages for users who would rather talk than type.
- Support built into the product because for a first-time digital-finance user, a stuck transaction needs a human quickly.
Results & Outcomes
Key Takeaway
- Model the balances you actually have. Collapsing user, group, pool and sub-account balances into one generic account type would have been faster and would have made the ledger unauditable. Distinct types plus an explicit transfer matrix is what makes group money reviewable.
- On these networks, idempotency is not optional. Retries are normal operation, not an edge case. Withdrawal handling had to assume the client would retry, because it will.
- Encode the governance the group already has. Two-manager minimums and approval gates were not invented for the software — they are how these groups already work. Putting them in code is what earned the trust to digitise the ledger at all.
- Participation can substitute for credit history. TrustScore turns consistent saving inside the platform into a basis for lending, which is how you extend credit to users the formal system has no record of.
- Transparency was the reason to switch. The feature that displaced the paper ledger was not the wallet or the loans. It was every member being able to see, at any moment, that the money is all still there.
Have a similar system to build or scale?
Let's discuss your engineering goals, architecture, and timeline.
Explore More Case Studies
Expenses Meet
An offline-first personal finance app built with Flutter and Firebase. Expenses Meet lets users track expenses without internet, auto-links transactions to their account on login, and adds group expense splitting and peer-to-peer loan tracking — all optimized for PKR.
E-CommerceSalveowell
Five product surfaces on one Laravel commerce and compensation platform, serving four regional markets since 2021: the public storefront, a retail shopping app with 100K+ installs, a distributor app, a training app, and an executive admin app. My role grew across the engagement from frontend developer, to sole developer of the retail app, to team lead over the rest.