How a Custom Inventory System Cut Our Supermarket's Expiry Losses by ~90%

I'm the Branch Manager of Jambo Supermarket, a 5-branch chain in Dar es Salaam. I'm also the developer who built our inventory system. That means this case study has something most vendor case studies don't: the person writing it is the person who suffers if the numbers are wrong.

How much was the supermarket actually losing?

Before we had systematic tracking, expiry losses at a single branch ran TZS 2–4 million per month — roughly $800–1,600, month after month, quietly written off. Products expired on shelves because nobody knew they were about to. By the time an expired item is found, every option is bad: it's already unsellable, usually past the supplier-return window, pure loss.

And that was only the loss we could see. The deeper problem was that we didn't actually know what we owned. More on that below — it turned out to be a TZS 200 million question.

What does the expiry monitoring system do differently?

The core idea is simple: move the moment of discovery from "after expiry" to "weeks before expiry." Staff scan products' barcodes and record expiry dates; the system continuously calculates days remaining for every tracked item and surfaces what needs action now — return to supplier, discount to sell through, or move to a faster-selling branch.

Today the system tracks roughly 9,000 items at the branch. Since deployment, 970–1,000 products have been saved from expiring — recovered through supplier returns, timely discounting, or inter-branch transfers, instead of being written off.

Run the math and the reduction comes out between 85% and 92%. On my website I quote it as "roughly 80%" — I'd rather under-promise a number I can defend on any given month than headline the best one.

How did stocktaking go from 8 days to 12 hours?

Our old full stocktake took 5 to 8 days. Days of counting on paper, transferring to Excel, arguing about which sheet was current, and recounting sections because two people counted the same aisle and their numbers couldn't be reconciled. For most of a week, the business ran half-blind while staff were consumed by the count.

With RetailOps, the same branch — 14,000+ products — is now counted in about 12 working hours: roughly 4 hours for the warehouse and 8 hours for the shop floor, with 15 staff scanning simultaneously.

Three design decisions made that possible:

• Concurrency-safe counting. Fifteen staff scan at the same time into the same counting session without overwriting each other — the system is built for parallel work, not one clipboard passed around.
• An append-only audit trail. Every single scan is logged permanently. Nothing is ever overwritten or silently edited. If a number looks wrong, we can trace exactly who scanned what, where, and when — which ends the "whose count is right?" arguments before they start.
• Offline scanning. The counting tool is a PWA that keeps working when the internet drops and syncs when it returns. In Dar es Salaam, this isn't a nice-to-have; a mid-count outage used to mean lost work.

The TZS 200 million surprise: what our first real count revealed

Here's the part that changed how our leadership thinks about inventory. When we ran the first full audit-trail count and compared physical reality against the stock value the old records showed, we uncovered a variance of over TZS 200 million — around 22% of book stock value.

Let that sink in: more than a fifth of the stock the business believed it owned wasn't actually there. Years of untracked shrinkage, unrecorded damages, receiving errors, and paper-count mistakes had quietly accumulated into the books. Every purchasing decision, every margin calculation, every "how are we doing?" conversation had been built on numbers that were 22% wrong.

A stocktake doesn't create the loss — it reveals the loss that was already there. The variance existed whether we measured it or not. The only choice was whether to know.

This is the real argument for audit-trail inventory systems, and it's bigger than expiry savings: until you can count accurately, your business is making decisions on fiction. After the correction, our system stock finally matched reality — and because every future count leaves a permanent scan trail, variance can now be caught per-count, per-item, per-staff-member, while it's still small.

What else runs on the platform?

Expiry monitoring and stocktaking are the headline modules, but RetailOps Suite grew into the branch's full back office: a product master with per-branch catalogs and Excel import/export, VAT-compliant quotations, invoices and customer statements, competitor price comparison, and supplier performance tracking. It's multi-tenant — built to serve other retailers, not just us — and available as a subscription from $30/branch/month, or as a custom build from $1,500.

What should other retailers take from this?

• Your expiry loss is bigger than you think, and mostly preventable. The difference between losing TZS 3M and TZS 250K a month wasn't working harder — it was knowing three weeks earlier.
• Your stock number is probably wrong. If you've never done a full count with a tamper-proof trail, assume a double-digit-percentage variance is hiding in your books. Ours was 22%.
• Speed changes behavior. When a count costs 8 days, you avoid counting. When it costs 12 hours, you count regularly — and problems get caught while they're small.
• Systems built on the shop floor fit the shop floor. Offline mode, concurrent scanning, append-only logs — every one of these exists because a real Monday morning demanded it.

Frequently asked questions