Retail vision systems fail on review capacity, not detection accuracy. Run the alerts-per-shift arithmetic before the pilot, and split safety from loss prevention.
Computer vision for retail safety works when the number of alerts it produces in a day is smaller than the number of alerts your staff can actually act on. That sounds obvious written down. It is also the most common reason these systems get quietly switched off within a quarter, and it has very little to do with how accurate the model is. A detector running at 95% accuracy across a store's daily traffic can still produce more flagged events than one loss prevention associate can review before close, and once the queue stops being reviewed the system stops existing.
We build computer vision systems for a living, over 30 production projects delivered since 2024, and the retail safety conversation follows a pattern. Everyone arrives wanting to talk about detection accuracy. The number that decides the outcome is alerts per shift against people per shift.
They share cameras, so they get budgeted as one line. They are not one line, and treating them as one is how scope doubles in month two.
Loss prevention is adversarial. Someone is actively trying to defeat it, the behaviour changes once staff start intervening, and the cost of a false accusation is enormous compared to the cost of a missed one. Safety monitoring is not adversarial at all. Nobody is trying to trick a spill detector or a blocked fire exit alert. The person who slipped would rather you had caught it.
That difference changes everything downstream. An adversarial system needs a review step with a human before anyone is approached, evidence retention that will survive a dispute, and a much more conservative threshold. A safety system can act on a lower confidence score, because the worst case of a false spill alert is somebody walking to aisle six and finding nothing. We covered the shared cost model for both in our retail computer vision ROI guide, but the build itself splits early.
If you only have budget for one, start with safety. It ships faster, it needs less legal review, and it gives you a working camera and event pipeline that the loss prevention project can reuse later.
Here is the arithmetic that gets skipped. Take a store running 800 self-checkout transactions a day. Suppose the model flags 5% of them for review. That is 40 alerts in a day. Now count the people. One associate covering the floor, handling their normal duties, realistically gets through something like a dozen alert reviews in a shift without the rest of the job falling over.
So 40 alerts arrive and roughly 12 get opened. The other 28 sit in a queue that nobody clears. Within a few weeks the queue has thousands of items in it, the associate has learned that the queue is not a real work item, and the dashboard becomes a thing shown to visiting executives rather than a thing anyone uses.
Notice that the model was not wrong in that story. It was doing exactly what it was asked. The system failed on capacity arithmetic that nobody ran before the pilot.
Run it first. Take your real transaction or footfall volume, multiply by the flag rate the vendor quotes, and divide by the number of humans who will be looking. If the answer is greater than one, either the threshold has to move up until it fits, or you need to accept that the system is a forensic search tool used after an incident rather than a live alerting tool. Both are legitimate. Confusing them is not.
Once you accept the capacity constraint, the fix is to flag fewer things. Every vendor will tell you they can tune the confidence threshold, and they can. What they will not tell you is which cases you are choosing to give up.
Push the threshold up and you keep the blatant events and lose the marginal ones. For self-checkout that usually means you keep the deliberate non-scan of a high value item and you lose the ambiguous produce weight substitution. For safety it usually means you keep the large obvious spill and lose the small one that is arguably the more dangerous trip hazard.
Someone in operations has to make that call with the numbers in front of them, and it has to be written down. In our experience this is the single most useful hour spent on a retail vision project, and it almost never appears on a project plan.
Prototypes lie. A detection demo that works on five clean recorded clips tells you nothing about the five thousand real ones, and moving from a demo that impresses a room to a system that holds up on a Saturday afternoon is where the actual engineering sits. We wrote about that gap in detail in our guide to custom computer vision development.
Retail is unusually harsh about this. Store lighting changes across the day and across seasons. Seasonal displays get built in front of cameras. Shoppers carry large bags, push carts that occlude half the frame, and wear coats in winter that change the silhouette the model was trained on. A model validated in September will drift by December for reasons that have nothing to do with the code.
The practical answer is the same as it is for factory floors. Fix the physical conditions before you touch the model, which is the argument we made in our visual inspection guide, and then plan for periodic re-validation rather than treating accuracy as a fixed property you measured once.
Detection is one box in the system. The alert has to reach a person, on a device they carry, with enough context to act, and the outcome has to be recorded somewhere that survives an audit. Most of the schedule goes there rather than into the model, which is the case we made in our retail vision integration guide.
For budgeting, our own bands are public. A single-purpose build, one detection type wired into one destination system, runs $4,000 to $10,000 over three to four weeks. A multi-step workflow, several detection types with routing, escalation and case management, runs $10,000 to $22,000 over five to seven weeks. A phased enterprise rollout across a fleet starts at $22,000 to $30,000 and runs eight to twelve weeks. Running costs for inference typically sit between $50 and $2,000 a month, and reasonable engineering choices around caching, model routing and how much video you actually send off the box cut that by three to ten times.
We have shipped safety software before, not only vision. Rope Access Logbook replaced a paper logbook for an industrial safety operation in eight weeks. Its founder, Chad Dubuisson, put it this way: "Codestreaks took our rough idea and turned it into a real product in just 8 weeks. The way they built it saved us months of headaches down the road." The lesson from that build transfers directly here. The value was not in the clever part. It was in making the record trustworthy enough that somebody would rely on it during an incident review.
Some stores should not do this yet, and it is worth saying plainly.
If you have no baseline measurement of your current shrink or incident rate, a pilot cannot be judged, because you will have nothing to compare the result against. If you have no one whose actual job is to respond to alerts, adding an alert source changes nothing. If your cameras cannot produce a stream in a format another system can read, you have a hardware project before you have a vision project. And if the store's genuine problem is staffing at the front end, a camera that watches the problem more precisely does not fix it.
Say no to those, fix the precondition, and come back. That is cheaper than a pilot that produces a number nobody trusts.
No, and framing it that way usually costs you the easier win. Slip and fall hazards, blocked fire exits, unattended spills, crowding at entry points and forklift proximity in stockrooms are all safety detections that need no adversarial handling and no legal review before someone responds. They tend to ship faster than loss prevention work for exactly that reason.
Partially, usually. The three honest tests are whether you can get the stream off the recorder in a readable format such as RTSP, whether the camera is aimed at the thing you want measured rather than at a door for evidence, and whether resolution at that distance is enough. Legacy installs often pass the first test and fail the second, so most sites end up with a mix of reused feeds and a few new cameras placed for the specific job.
There is no universal number, because the answer depends on how many people you have to review alerts. Work it backwards instead. Decide how many alerts one person can genuinely review in a shift, multiply by the number of reviewers, and that is your daily alert budget. The acceptable rate is whatever keeps you under it.
For a single-purpose build in the $4,000 to $10,000 range, tied to a measured baseline, payback inside a year is a reasonable target. It depends far more on whether anyone acts on the alerts than on the detection quality, which is why we push so hard on the capacity arithmetic before the build rather than after.
Decide it on bandwidth and site count, not preference. Streaming continuous video from many stores is a real network bill and a real dependency on connectivity that retail sites often do not have. Running inference on a small box in the stockroom and sending only event data collapses that. Cloud is reasonable when you have few sites, good uplinks, or a model you expect to retrain often.
Written by the Codestreaks team, edited by Arsalan Amin. The cost bands, timelines and running cost figures are our own published pricing for this class of build, not industry averages. The Rope Access Logbook timeline and the quote from its founder are from a real engagement. The 800 transaction example is arithmetic used to demonstrate the capacity constraint, not a measured client result, and it is labelled as such in the text. Drafting is AI assisted and every post gets a human editing pass against real project data before it ships.
If you are weighing a retail vision build, the useful first hour is not a vendor demo. It is running your own alert capacity arithmetic and deciding which marginal cases you are willing to give up. We are happy to do that with you on a free 30 minute scoping call, and we will tell you if the answer is that you should not build this yet.
You can see how we approach this class of work on our computer vision development page, or start a project and tell us what you are trying to measure. We reply within two business days.
A serial maker of SaaS products and AI agents, I’ve built and launched 10+ tools, grown products to thousands of users, and taken multiple ventures. I share the process what works, what breaks, and how builders can ship faster and smarter. Previously a data scientist at a Big Four consulting firm.
