Most computer-vision projects start with a proof of concept, and most PoCs prove the wrong thing. They show a model lighting up bounding boxes on a clean, well-lit clip in a conference room — which proves the technology exists, something you already knew. A PoC worth running answers a sharper, more uncomfortable question: will this work on your cameras, in your conditions, often enough to be worth building? Here's how I scope one so the answer means something.
Prove it on your worst footage, not your best
The fastest way to fool yourself is to validate on the footage where the model obviously works. A real PoC does the opposite: it goes looking for the hard frames — the backlit doorway at 7am, the camera half-occluded by a forklift, the rainy night shift, the operator wearing a hood. If the model holds up on the ugly cases, the clean ones take care of themselves. If it only works on the demo reel, you've proven nothing you can deploy.
Define "good enough" before you start
"Does it work?" has no answer. "Does it catch at least the events that matter, without so many false alarms that people stop trusting it?" does. Before a single frame is processed, a PoC should name the bar: which misses are unacceptable, which false positives are tolerable, and what the system does when it's unsure. A detector that's right 80% of the time can be a triumph or a failure depending entirely on which 20% it gets wrong — and that's a conversation to have up front, not after.
Test the pipeline, not just the model
A model that scores well in a notebook is not a system. A PoC should run end to end, even if crudely: pull a real RTSP feed, run inference at something close to the real frame rate, and surface the result as an event — not a folder of saved images. That's where the latency budget and the integration realities show up, and it's exactly the gap where projects quietly die between the notebook and the line.
Keep it cheap and time-boxed
A PoC's whole value is that it's a small bet that de-risks a large one. If it takes three months and a six-figure budget, it isn't a proof of concept — it's the project, run on hope. Scope it to weeks, on a narrow slice of the problem, with a clear yes/no decision at the end. The deliverable isn't a polished product. It's an honest answer: build it, reshape it, or walk away — with evidence either way.
The honest version
The best outcome of a PoC is sometimes a clear "no" that saved you a year. That's not a failure; it's the cheapest a vision project will ever be to stop. A good proof of concept is built to be killable — fast, narrow, and ruthless about your real conditions — so that the projects that do move forward are the ones that deserve to.
If you've got a camera feed and a decision riding on it, that's exactly the kind of PoC worth scoping together — book a call.