The fastest way to lose money on computer vision is to use it where a simpler tool would have worked. A camera and a model feel modern and capable, so they get reached for first — even when the problem doesn't need pixels at all. The honest part of this work isn't building the detector. It's knowing, before anyone spends a budget, whether vision is the right tool in the first place.
Here are the tests I run before saying yes.
When a cheaper sensor already measures it
Vision earns its place when the information you need only exists as an image — shape, position, a person's posture, what's on a belt. If the thing you care about can be read directly by a load cell, a temperature probe, a proximity switch, an encoder, or an RFID tag, that sensor will almost always be cheaper, more accurate, and easier to trust than inferring the same number from a camera.
A good question to ask first: if I could attach one perfect sensor to this problem, would it be a camera? If the answer is "actually, a scale would do it," then vision is the expensive path to a number you can already get.
When the decision can't tolerate the error rate
Every vision model is probabilistic. It will be wrong sometimes — in bad light, on an occluded object, on a case it never saw in training. That's fine when a person stays in the loop, when the cost of a single miss is low, or when the system can fail safe. It is not fine when one undetected event is catastrophic and there's no backup. If your process needs a hard guarantee, vision belongs beside an interlock, not instead of one. Be honest about which one you're building.
When you can't get the data
A model is only as good as the footage behind it — and specifically the footage of the cases that matter. If the hazard you want to catch happens twice a year, or the defect is rare by design, you may not have enough examples to train or even to validate against. This is the constraint people discover last and pay for most. It's the same gap that sinks projects after launch, the one I wrote about in why computer vision fails in production: clean test numbers don't survive contact with the edge cases that actually occur on-site.
When the real fix is the process, not perception
Sometimes "detect when someone enters the danger zone" is really "people keep entering the danger zone." A light curtain, a physical barrier, or a machine interlock can remove the hazard outright, rather than detecting it after the fact. Vision is the right call when you genuinely can't change the process — when you need to observe a live, messy reality you don't control. When you can change the process, often you should, and skip the model entirely.
What vision is actually good at
None of this is an argument against computer vision. It's the case for using it on purpose. Vision is unmatched when the signal only exists as pixels, when the environment is too variable for a fixed sensor, when you need to reuse cameras you already have, and when a probabilistic answer delivered in real time is genuinely useful. That's a large and valuable space — it's just smaller than the marketing implies.
So the most useful thing I can do on a first call is sometimes to talk you out of a vision project. If you have a camera and a problem worth solving, I'll tell you straight whether it's the right tool — book a call.