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

A property manager receives a rent transfer. The name on the bank alert does not match the tenant’s name. The proof is a screenshot inside a WhatsApp chat. The landlord is somewhere else and wants a statement that explains what was paid, what remains outstanding, and which repair reduced the balance.

Most property software begins from a cleaner world. The tenant, payer, lease, property, and bank transaction all line up. A staff member enters the payment, the ledger updates, and the report is complete.

The real work begins where those assumptions stop.

That was one of the design lessons behind Gidabook. The product needed authenticated workspaces, payment records, owner reporting, secure share links, and a place for the evidence around a transaction. The record could not merely say that rent was paid. It had to help the person managing the property explain why that payment belonged to that tenant and show the landlord enough proof to trust the report.

The screenshot and the mismatched payer name are not untidy details around the workflow. They are the workflow.

I had already met the same mistake while building Brik. Conventional invoicing software treats the invoice as a document that leaves an accounting system by email. For many Nigerian small businesses, the commercial conversation is already happening in WhatsApp and the payment will be a bank transfer. Asking the owner to move the relationship into a new portal before the software creates value is not adoption. It is a request to do extra work.

So Brik attaches a record to behaviour that already exists. The invoice is a link shared into the open conversation. The customer sees what they owe. The payment can follow the transfer path they already understand. The system keeps the record that the chat alone would lose.

Two different products produced the same rule: do not design from the policy manual until you have watched the workaround.

The workaround often contains more operating intelligence than the formal process. A screenshot exists because the people involved need portable proof. A WhatsApp reminder exists because collection is also a relationship. A payment from another person’s account exists because access to money and accounts does not always follow the neat identity model in the database.

Software built for the supposed world treats each of these as an exception. The team adds a note field, creates an offline spreadsheet, or keeps the real explanation in chat. The new system becomes one more place to update while the old system remains the source of truth.

This is why a polished demo can be misleading. It shows the path where every field is known, every actor follows the sequence, and every integration returns the expected answer. A company does not need help with that path. It needs help with the transfer that cannot be matched, the approval that happens outside the application, the customer who has only a phone, and the report that must carry enough evidence for someone far away to believe it.

Before I scope software for an operating team, I now map five things:

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

The fifth question prevents a common fiction. A process does not become digital because a diagram puts every step inside a box. If staff will still use WhatsApp, paper, a bank application, or a phone call, the software must have a deliberate boundary with that behaviour. Otherwise the boundary will still exist, but nobody will own it.

AI does not remove this requirement. An AI layer placed on top of a false workflow can summarise the wrong record, automate the wrong handoff, and make the gap harder to see. The valuable use of AI comes after the operating truth is understood: extracting a reference from evidence, drafting a careful follow-up, flagging a mismatch for review, or turning scattered records into a report a person can verify.

That order matters. First understand the work. Then decide what should be recorded, what can be automated, and what must remain a human decision.

The opportunity in African business software is not to make local companies behave like textbook examples. It is to take the systems they have already invented, preserve what makes them work, and remove the parts that make growth hard to see or trust.

If a software project keeps fighting the way your organisation operates, the first question is not which feature to add. It is which assumption in the design was never true. Finding that gap is part of my product and launch audit.