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

I was creating an invoice in Brik, added an item for ₦450,000, and the running total showed ₦4,500.

Apart from that number, nothing looked wrong. The screen opened fine, took the item and updated the total. It was just out by a factor of a hundred, which is about the worst mistake you can make in software that helps people ask to be paid.

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

With money, this kind of mistake hides easily. A number like 450000 looks fine whether it means naira or kobo. To the software they’re both just numbers. Only the person who knows what the invoice should say can tell the meaning changed somewhere along the way.

I could have just fixed the display on that screen. That would have made it look right and left the same problem waiting for the next screen.

What I did instead was move the mobile running total into one shared calculation that follows the same steps as the part of Brik that creates the invoice. Each price is changed from naira to kobo before it’s multiplied by the quantity. The web version was already doing this correctly.

Then I added tests for the original ₦450,000 case, several line items, quantities, rounding, half-filled rows and bad input.

Those tests were needed because the mobile screen and the invoice were treating the same number differently. Fixing the text on one screen wasn’t enough. The running total needed a clear unit and had to follow the same calculation as the invoice.

This is how payment software can seem fine for weeks and still be risky. The normal path looks convincing: the buttons work, the totals move, the payment page opens. A small disagreement between two parts of the app can sit there until a real amount brings it out.

Now, whenever money passes from one part of a product to another, I ask what unit the amount is in and where the product makes that clear. Calling it “amount” or “price” doesn’t tell you.

That rule needs to live in the product and its tests, not just in the head of whoever built the first version.

It’s also how I look at a release that feels almost ready. I look for places where two parts of the product quietly disagree: what an amount means, who’s signed in, what that person is allowed to do, and what happens after something fails. One clear mismatch is usually worth more than a long list of general advice.

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