A stock audit took two to three people a full weekend. Now it takes ten minutes.
- Client
- An RFID inventory software vendor serving optical and small retail
- Scale
- Many retailers on one platform, several stores each
- Engagement
- A platform build, then a takeover of the scanning apps
The outcome in five lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| A full stock audit1 | 2 to 3 staff, a full weekend | 10 minutes | Measured |
| Theft or misplacement found2 | unnoticed for long periods | within 5 working days | Measured |
| Product catalogs to maintain3 | one per store | one, shared by every retailer | Described |
| Scanning apps to build and release4 | one per reader vendor | one, with an adapter per vendor | Described |
| Reordering from a vendor3 | raised by hand after a count | automatic, or one click at preset quantities | Described |
Two lines are measured. Three describe how the system works now and carry no number. The small number beside each line says how it was measured.
The problem, in the client's terms
Stock audits were manual. In an optical store, two to three staff spent an entire weekend counting frames, and a full count often meant closing part of the shop. Counts were wrong often enough that the stock record could not be trusted, items ended up in the wrong place, and theft went undetected for long periods.
A hand count is only true for the moment it is taken. Between counts the stock record and the shelf drift apart, and everything downstream inherits the drift: what gets reordered, what gets written off, and what a customer is told is in stock.
RFID does not fix this on its own. A reader reports only part of what is in front of it, so a platform built on raw reads carries a different kind of error. The design had to start there.
- ConstraintStore staff are not technical. Nothing new to learn beyond pointing a reader.
- ConstraintMany retailers share one platform, and none may see another's stock.
- ConstraintStores buy readers from different vendors, so no retailer could be locked to one device.
The architecture, before and after
Switch between the two. The count moved from people to readers, the catalog moved from each store to one shared service, and the scanning apps became one.
- What hurt in this state
- Built in this engagement
Three decisions, and what we turned down
The stack is the easy part to copy. The choices behind it are what made it work, so each one names what it replaced and what it cost.
Automate on a reconciled count, not on raw reads
Turned down
Reorder straight from what readers report
A reader misses part of what is in front of it, so automation on raw reads repeats that error at scale.
Chosen
Reads, then a count that can be trusted, then reordering
Scans are compared with the stock record first, flagging items in the wrong place or missing, and only the reconciled count drives an order.
What it cost: A scan is not a count until it is reconciled, so an order can fire only after the comparison runs rather than the moment a tag is read.
One master catalog instead of one per store
Turned down
Each store maintains its own catalog
Every store repeats the same data entry, and each store's mistakes stay local and undetected.
Chosen
A master catalog every retailer draws from
Seeded by the admin team, enriched by every retailer's data, kept current against an optical frames data feed, with manufacturer SKU checks to catch tagging errors.
What it cost: Shared product data had to be kept strictly apart from each retailer's own stock, and the feed became a dependency the platform has to keep in sync.
One scanning app with adapters, not one app per device
Turned down
Keep an app per reader vendor
Every fix and every store approval multiplies with each device supported.
Chosen
An adapter layer over the vendor SDKs
The app talks to one interface for re-reads and read range; a new device is a new adapter, not a new app.
What it cost: Taking over and merging existing codebases meant retesting every device path, and each vendor SDK's quirks still had to be handled inside its adapter.
How it was delivered
Reads first, then a count that can be trusted, then everything that depends on the count.
Reads
Tagging, reader integration, re-read handling and read-range control across three vendor SDKs.
A count that can be trusted
Scans compared with the stock record to flag missing and misplaced items.
Catalog and SKU checks
The master catalog, the frames data feed and manufacturer SKU validation.
Replenishment
Purchase orders to vendors, automatic when stock runs low or one click at preset quantities.
Scanning app consolidation
The separate device apps merged into one Android app with an adapter per SDK.
Who owns what now
The client runs the platform and sells it on to retailers as a service.
Results
What a store spends to know what is on its shelves, before and after.
- Store staff point a reader instead of counting by hand, so an audit no longer needs a weekend.
- Owners see missing or misplaced stock at the next weekly scan instead of the next full count.
- The vendor's own team ships one scanning app instead of one per device.
Stock accuracy was not measured as a number, so no accuracy figure is claimed.
a full weekend
Before, a full weekend
10 minutes
After, one scan
An audit that closed part of the shop for a weekend now fits between customers.
| Option | Minutes of elapsed audit time, with a full weekend taken as two 8-hour working days. |
|---|---|
| Before, a full weekend | a full weekend |
| After, one scan | 10 minutes |
Source: Source note 1
What it would be worth to you
We do not publish what an engagement costs. So this works from your side: what your audits cost today, and what they would cost at ten minutes.
Labour saved per year
$7,876
- Audit hours per year, today
- 384 h
- Scan hours per year, after
- 26 h
- Payback on your cost
- Enter a cost
More checks for less time. Stock is checked 52 times a year instead of 4.
What went wrong, and what we would change
Every reader vendor behaved differently
Hardware integration took far more testing than planned. Re-reads and read range differ by device and SDK, and those differences surfaced one device at a time. Next time, a device lab with every supported reader goes in during the first week, not as each one arrives.
Store staff needed more than a manual
Store staff needed training. A reader is simple to point and easy to point badly. What we would change: build the guidance into the scan screen itself, so a new store needs no session to get an audit right.
Will this work for your stores?
It fits when
- You run several stores and a count has to be right because something automated acts on it.
- Items are small, numerous and easy to misplace, as frames are.
- A tag's cost is small against the unit price of what it is stuck to.
Look elsewhere when
- You have one store and a small range. A barcode cycle count may be enough.
- Your goods are cheap per unit. The tag becomes a real share of the margin.
- You need an exact count at every moment. Readers miss tags, so a count is reconciled, not read.
Check it yourself after your next audit
If the hours run into days and the gaps run into weeks, this case study is about you. Put the hours into the calculator above.
- Write down the staff hours the audit took, across every store.
- Count the items where the audit and the stock record disagreed.
- Note how long ago each missing item was last seen in your stock records.
The stack, by layer
- DevicesRFID readers from three hardware vendors, and RFID printers
- MobileOne Android app in Kotlin and Java, with an adapter layer over the vendor SDKs
- PlatformLaravel split into services, JWT authentication, Redis queues
- IntegrationNode.js services over RabbitMQ, an optical frames data feed
- DataMySQL and MongoDB for records and logging, on dedicated servers
How each figure was measured
- Staff time for one full store audit, before the platform and with it.
- Weekly scans compared against the stock record, flagging missing or misplaced items within five working days.
- How the platform works: one shared catalog with manufacturer SKU checks, and purchase orders raised from the reconciled count.
- One Android app replaced the separate app each reader vendor required.
- Reported by the client after the scanning apps were merged.
Tell us how long your last audit took, and we will tell you if RFID pays.
Send the staff hours and the number of stores. A software engineer reads it and replies with an honest answer, including when barcodes are the better choice.