I entered ₦450,000. The app showed ₦4,500

While I was creating an invoice in Brik, a ₦450,000 item made the running total show ₦4,500.

Apart from the number, nothing about the invoice screen looked broken: it opened normally, accepted the item, and updated the total. Yet the result was wrong by a factor of one hundred, which is about the worst kind of failure for software that helps people ask to be paid.

The cause was ordinary. The form held the price in naira. The part that turned the running total into text expected kobo, so it divided the same number by one hundred.

Money makes this class of mistake unusually easy to hide. A number such as 450000 looks valid whether it means naira or kobo. To the software, both are ordinary numbers. Only the person who knows what the invoice should say can see that the meaning changed along the way.

My first instinct could have been to correct the display where the error appeared. That would have made this screen look right and left the underlying problem available to the next screen.

Instead, I moved the mobile running total into one shared calculation and made it follow the same order as the part of Brik that creates the invoice. Each price changes from naira to kobo before it is multiplied by the quantity. The web version already did this correctly.

Then I added checks for the original ₦450,000 case, multiple line items, quantities, rounding, unfinished rows, and invalid input.

Those checks mattered because the mobile display and the part of Brik that creates the invoice handled the same number differently. Correcting the text on one screen was not enough. The running total needed a clear unit and had to follow the same calculation as the invoice.

This is why payment software can feel fine for weeks and still carry serious risk. The normal path is visually convincing because the buttons work, totals move, and the payment page opens. A small disagreement between two parts of the app can survive until a real amount exposes it.

Whenever money moves from one part of a product to another, I now ask what unit the amount is in and where the product makes that unit clear. A name such as “amount” or “price” is not enough.

The rule should live in the product and its checks, not only in the memory of the person who built the first version.

That is also how I approach a release that feels almost ready. I look for the places where two parts of the product quietly disagree: what an amount means, who is signed in, what that person can do, and what happens after something fails. One clear mismatch is often more valuable than a long list of general advice.

If you have a product that works in the demo but still feels risky to release, that is the work behind my Launch Rescue service.