The invoice is a WhatsApp message

Every invoicing product I studied before building Brik made the same four assumptions. An invoice is a document. It travels by email. It gets paid by card or direct debit. It reconciles neatly into accounting software.

Then I watched how money actually moves for the businesses around me in Lagos.

The invoice is a WhatsApp message. Sometimes typed, sometimes a photo of a handwritten list, sometimes just “Your total is 47,500.” The payment is a bank transfer, made from a phone, often while the chat is still open. The receipt is a screenshot. The reminder, when payment is slow, is a carefully worded “Good morning ma” that has to balance firmness against relationship, because the customer is probably also a neighbour, a fellow church member, or a repeat buyer you cannot afford to offend.

None of this is broken. That is the part most software gets wrong. The system is fast, it runs on trust, it works on any phone, and it costs nothing. A tool that treats it as informality to be corrected is asking a business to abandon something that works for something that might.

But the system has real costs, and the people inside it feel them every day. Records live in chat scroll, so proving income to a bank is nearly impossible. Receivables exist in memory. Debts go stale because chasing them is socially expensive. The owner knows roughly who owes what, and roughly is the problem. The cost is not inefficiency today; it is invisibility tomorrow. A business with no records cannot get a loan, cannot price its own growth, cannot be sold, and cannot always tell whether it is actually profitable.

So the design question for Brik was never “how do we get Nigerian businesses to send proper invoices.” It was “how do we let the WhatsApp and bank transfer system keep working, and quietly attach records to it.” In Brik, an invoice is a link you drop into the chat that is already open. The customer taps it, sees what they owe, and pays the way they already pay: by transfer. Confirmation is automatic. The records accumulate as a side effect of behaviour that was already happening. Nobody had to be retrained. Nothing about the relationship changed.

That principle got tested quickly. In the early builds, every feature that asked users to change behaviour stalled. Every feature that attached itself to existing behaviour got used. I now treat that as a law of this market.

If you run an organisation and you are evaluating software, or AI, the vendor demo is answering a question nobody asked. The demo assumes the textbook process. Your first question should be: what do my people and my customers actually do, today, with the tools they already trust? Adopt things that attach to that. Be suspicious of things that require your market to become a different market before the value shows up.

The gap between how business is supposed to work and how it actually works here is not a defect. It is information, and it is the cheapest competitive research available, because almost everyone building for Africa from a distance ignores it. Products built around it feel obvious in hindsight. That gap is where I build, and it is what these essays are about.

I am writing one of these every week. If that question, what does my market actually do, is one you are living with, the essays are for you.