Software built for how business is supposed to happen vs how it happens here

A property manager gets a rent transfer. The name on the bank alert isn’t the tenant’s name. The proof of payment is a screenshot in a WhatsApp chat. The landlord lives somewhere else and wants a statement showing what was paid, what’s still owed, and which repair came off the balance.

Most property software assumes a tidier world. The tenant, the person paying, the lease, the property and the bank transaction all match. Someone enters the payment, the ledger updates, and the report is done.

The real work starts where that stops being true.

That was one of the things I had to design for in Gidabook. It needed logins for each workspace, payment records, reports for owners, secure links to share them, and somewhere to keep the evidence behind each transaction. It wasn’t enough for the record to say the rent was paid. It had to help the manager explain why that payment belonged to that tenant, and give the landlord enough proof to believe the report.

The screenshot and the wrong name on the transfer aren’t messy details around the work. They are the work.

I’d already run into the same thing building Brik. Normal invoicing software treats an invoice as a document that leaves an accounting system by email. For a lot of small businesses in Nigeria, the conversation with the customer is already happening on WhatsApp and the payment will be a bank transfer. Asking the owner to move all that into a new portal before they get anything out of it isn’t adoption. It’s just more work for them.

So Brik adds a record to what people already do. The invoice is a link dropped into the chat that’s already open. The customer sees what they owe and pays by transfer the way they normally would. Brik keeps the record that the chat on its own would lose.

Two different products taught me the same thing: don’t design from the policy manual until you’ve seen the workaround.

The workaround often knows more about how the business runs than the official process does. The screenshot is there because people need proof they can pass around. The WhatsApp reminder is there because collecting money is also about the relationship. The payment from someone else’s account is there because who has access to money doesn’t always match the neat picture in the database.

Software built for the ideal world treats all of these as exceptions. The team adds a notes field, keeps a spreadsheet on the side, or leaves the real explanation in the chat. The new system becomes one more thing to update, and the old way stays the one people actually trust.

That’s why a polished demo can mislead you. It shows the path where every field is filled in, everyone does things in order and every connection to another system works. Nobody needs help with that path. They need help with the transfer that won’t match, the approval that happens outside the app, the customer who only has a phone, and the report that has to carry enough evidence for someone far away to believe it.

Before I plan software for a team now, I map five things:

Where the request actually starts.
What people do before any software is involved.
What counts as proof that the work or payment happened.
Who sorts out a mismatch, and what they need to decide.
Which parts people will keep doing outside the new system.

The fifth one stops a common pretence. A process doesn’t become digital because a diagram puts every step in a box. If staff will still use WhatsApp, paper, a banking app or a phone call, the software needs a clear line where it hands over to that. Otherwise the line still exists, but nobody’s responsible for it.

AI doesn’t change this. Put AI on top of a workflow that isn’t real and it can summarise the wrong record, automate the wrong handover, and make the gap harder to see. AI is useful once you understand how the work really happens: pulling a reference number out of a screenshot, drafting a polite follow-up, flagging a mismatch for someone to check, or turning scattered records into a report a person can verify.

The order matters. Understand the work first. Then decide what should be recorded, what can be automated, and what has to stay a human decision.

The opportunity in business software for Africa isn’t making local companies behave like textbook examples. It’s taking the systems they’ve already worked out, keeping what works about them, and fixing the parts that make growth hard to see or trust.

If a software project keeps fighting the way your company works, don’t start by asking which feature to add. Ask which assumption in the design was never true. Finding that is part of my product and launch audit.