The Blue Zone Africa admin backoffice dashboard. Client names are redacted.

Blue Zone Africa sells preventive healthcare through a national network of ambassadors who earn on what they bring in. When we started, all of it ran on spreadsheets, WhatsApp and trust. We built the software that runs it now, from an empty repository.

41
Ambassadors on it
25
Screens designed
11
Network generations
7
Training courses
The work

Money, people and trust. In that order.

01 Research

Four months of asking before a line of it was designed.

A system that pays people cannot be specified from a brief. Get a commission rule wrong and you have not shipped a bug, you have underpaid somebody who recruited their own church. So the first phase was research, in four strands.

  • We mapped the process that already existed. How a transaction got recorded, who checked it, who approved it, where the money physically moved, and which parts lived in one person's head. You cannot replace a manual process you have only been told about.
  • We interviewed ambassadors and admins. Not about features. About what they actually do all day, where they get stuck, and what they ask each other. Two of the smallest decisions in the finished product came straight out of this, and both are further down this page.
  • We read the compensation model against itself. The funds-distribution board paper, the published commission rates, and what each package can actually afford to pay. This is the strand that found the most, and the reason one feature is deliberately not built.
  • We worked out who needs telling, and what they are supposed to do about it. Every state a transaction, a withdrawal or a registration can enter, which of the three roles needs to hear about it, and what action is expected of them when they do. That study is what the whole notification layer was built from, rather than adding emails wherever somebody complained.
02 The build

One system, two audiences, twenty-five screens.

What shipped is a member portal and an administrative backoffice that share one database and one design language. Thirteen screens for ambassadors, twelve for the office.

Ambassadors see their wallet, record transactions, request withdrawals, manage their account and look at their network. Administrators approve or decline, manage members and staff, run reports, and issue the payment references that tie a bank statement back to a payout. Every rule that decides money lives in the database rather than in the browser, because a rule enforced only on screen is a suggestion.

It went live to real ambassadors handling real money in July, after an end-to-end review of every screen and every calculation in it.

The admin backoffice dashboard, with client names redacted Client names redacted. Everything else is the live backoffice.
03 The network

Eleven generations deep, and deliberately less contact detail than it could show.

An ambassador's network is the business. The first version could only show the people someone had personally introduced, which is the one part they already knew. It now shows the full network eleven generations down, as a tree or as a table, with each person's join date, package, account status and the business they have generated.

Contact details appear for the first two generations only. Technically we could have shown all eleven. Those are the people an ambassador actually works with, and a downline is a list of other people's phone numbers before it is anything else.

04 Getting paid

We deleted a step, and caught something that would have paid every commission twice.

Approved commission used to land in a stage called Pending Earnings and wait for an admin to release it separately. Ambassadors kept asking what it meant, and the honest answer was nothing: the money had already been approved. The stage is gone. Approving a transaction now puts the commission straight into the wallet, split 80% to the withdrawable balance and 20% to Lifestyle Savings. No money leaves the business any earlier than it did before, because that still only happens when a withdrawal is approved.

Which is where the research earned its keep. The in-portal guidance for admins described sending a bank transfer when releasing a commission, and sending one again when approving the withdrawal of that same money. Followed literally, it would have paid every commission twice. The guidance now states plainly that money leaves at one point only. A published commission rate that did not match what the system actually pays was corrected in the same pass.

  • A withdrawal can no longer exceed a balance. Nothing had been stopping it, and the result would have been a negative wallet and a real discrepancy to unpick months later. The check sits in the database, so it holds whichever route the request arrives through.
  • The registration fee now gates the money, not the membership. The fee was recorded and displayed but prevented nothing, so someone who had never paid could still accrue and withdraw. A withdrawal now waits on it. Joining, recruiting and earning stay instant, because holding up new members would cost more than it saves.
  • Payment references are issued centrally. They used to be produced by whichever laptop opened a small page, which checked for duplicates only against itself. Two admins could issue the same reference on the same day, and that reference is the only thing tying a bank line to a payout. Every one is now recorded as it is created, visible to every admin, and a repeat is impossible rather than unlikely. Characters that are easily confused read aloud are left out of the alphabet entirely.
The payment-reference tool in the admin backoffice
05 Automation

Nobody should have to log in to find out what happened.

This is the notification research, built. Ambassadors used to have to sign in and go looking to learn whether a transaction had been approved or a withdrawal paid, and a declined withdrawal was invisible until they checked.

  • Ambassadors are emailed on all four outcomes, approved or declined, transaction or withdrawal, carrying the reason where one applies and a link to the transfer receipt when money goes out.
  • Management is emailed the moment something needs them: a transaction uploaded, a withdrawal requested, a registration, a fee confirmed, an account deactivated, a staff account created. Each is labelled by type so it can be filed automatically instead of arriving as one undifferentiated stream.
  • A nine-email series carries a new ambassador's first weeks: welcome, how to record a transaction, how to grow a network, how the money works, a fraud warning, and three payment reminders. They send themselves at the right moment rather than being chased.
  • Thirteen system email templates were rewritten in the brand's own voice. Sign-up confirmations and password resets had been going out as unbranded defaults that looked like they came from a software vendor.
  • Everyone who registers joins the mailing list automatically, whether they signed up themselves or an admin added them. Without that, none of the above is possible.
06 Handover

Seven training courses, and four things we changed rather than documented.

Software a network cannot use is a cost. We wrote seven word-for-word training courses covering getting started, recording transactions, withdrawals, growing your network, understanding your money, account management and staying informed, delivered as narration-ready scripts and as Word and PDF documents so anyone can read or record them without touching the project.

Writing them was its own audit. Checking each line against what the portal actually did turned up four places where the two disagreed. We corrected the behaviour instead of describing it, because a training video that documents a quirk teaches the quirk.

Two of the smallest changes in the whole project came out of listening to ambassadors, and both are about memory rather than software. Referral codes can now be searched by their last six characters, because that is the part people read out to each other. And password rules dropped to eight characters with a letter and a number, after support kept getting calls from people stuck on the special character.

07 Continuity

A money system has to be trustworthy on its worst day.

Three pieces of work that no ambassador will ever see, and that the business would have felt badly if they had been skipped.

  • There was no backup of any kind. Every ambassador, their earnings and their wallet balances existed in exactly one place, on a plan that keeps no copies. A copy is now taken nightly, encrypted before it leaves, and stored away from the system it came from. It reports a failure rather than stopping quietly. We restored it and checked the records were all there, because a backup nobody has opened is only a belief that one exists.
  • The rules themselves were only in the live system. The logic that calculates commissions, splits wallets and controls access existed nowhere else, so losing it meant rebuilding from memory. It is now recorded outside the system and can be restored exactly as it was.
  • Account permissions were tightened and the default reversed. Anything newly added used to start life open. It now starts closed and has to be deliberately opened, with each tool carrying its own check as a second layer. Every account holding elevated permissions was listed and reviewed, and all of them belong to named people.
08 Judgement

The feature we researched, costed, and refused to build.

Paying commission across four generations of a network was fully investigated and ready to build. It has not been built, and that is the decision we are most confident about on this project.

Reading the compensation model against itself raised three problems. The funds-distribution board paper does not describe a generation model at all, and reserves only a small share for anything beyond the direct referrer. The published rate for a direct referral disagrees with what the system actually pays on three of the four packages. And the total payable across all generations can exceed what the board paper sets aside, leaving a shortfall on every single registration.

Building it would have put wrong numbers into real people's wallets, at scale, in a business whose entire proposition is that ambassadors can trust what they are owed. So it sits on hold with the three questions written down in plain language and addressed to the people who can answer them. Knowing when not to ship is part of the job.

What it runs on

The stack.

Front-end
React 18, Vite, Tailwind CSS, 25 screens across two audiences
Database
PostgreSQL with row-level security, stored procedures for every money operation, triggers and scheduled jobs
Platform
Supabase for authentication, storage policies, serverless functions and the REST layer
Automation
Database webhooks into serverless functions, transactional and lifecycle email, mailing-list sync, secrets held in a managed vault
Continuity
Nightly encrypted off-site backups, restore-tested. Database logic version-controlled outside the live system
Reporting
A plain-language update log the leadership team reads, generated from a single source file rather than written weekly by hand
Next project

Blue Zone Africa Store

View case study