A model that scores 95% mAP in a notebook and a model that runs reliably on a live camera feed every shift are two very different things. The gap between them is where most computer-vision projects quietly stall. Here is where they break, and what it takes to close it.
The demo works. The deployment doesn't.
The first version always looks great. You have clean footage, a well-lit scene, and a test set that resembles your training data. Then it meets the real world: a camera mounted at an awkward angle, rain on the lens, a night shift under sodium lights, a worker half-occluded by equipment. Accuracy that looked solved on paper falls apart on the edge cases that happen all day, every day.
Production computer vision is mostly about the conditions you didn't train for.
Three failure modes that matter
- Domain shift. The live feed never looks exactly like your dataset. Lighting, weather, camera placement, and lens dirt all move the distribution out from under the model. You plan for this with continual evaluation, not a one-time test score.
- Latency and throughput. A model that takes 400 ms per frame is fine in a notebook and useless on a 25-fps multi-camera stream. Real deployments live or die on GPU-optimized inference, batching, and a pipeline that keeps up with the cameras.
- The system around the model. Ingesting RTSP streams, decoding video on the GPU, tracking objects across frames, raising an alert exactly once instead of a hundred times — that surrounding system is most of the work, and it's the part a research metric never measures.
Treat it like software, not a science project
The systems that survive in production share a few traits. They are packaged so they deploy the same way every time. They expose metrics so you can see drift before it becomes downtime. They make models interchangeable, so a better detector ships without rebuilding the whole pipeline. And they fail safely — a dropped frame or a dead camera degrades gracefully instead of taking the line down.
None of that is glamorous. All of it is the difference between a demo and a system someone trusts on a real camera feed.
The short version
If you're evaluating a computer-vision idea, judge it by the boring questions: How does it behave at 3 a.m. in bad weather? How fast is one frame, and how many cameras at once? How do you know when it starts to drift? Answer those before the accuracy number, and you're already ahead of most projects.
That's the work I do — turning a promising model into a system that runs reliably on real cameras. If you have a feed and a problem worth solving, book a call.