A computer vision pilot can look flawless in a demo and still fall apart on the factory floor. The reasons are rarely mysterious.

Teams that bring in computer vision consulting services before training a single model usually find those problems while fixing them is cheap, not after months of GPU bills and rework.

This article explains where pilots break, what expert advice before a build should cover, how long it takes and how to judge an advisor.

Where Pilots Actually Break

Most failed projects share a short list of causes, and almost none of them is the neural network itself. The model is the part that engineers enjoy, so it receives the attention, while the surrounding conditions quietly decide the outcome.

The first culprit is the gap between lab and field: models trained on clean, well-lit images meet dust, glare, vibration and dirty lenses. Closely related is the camera itself. If a scratch is invisible at the chosen resolution, angle or lighting, no model can find it, which is why optics deserve attention before algorithms. Data is the next weak point, since poor labels, class imbalance and drift between training and production cause most underperformance.

Accuracy targets are another trap, because chasing the last few percentage points can demand far more data and compute than the business case can bear. Teams also misjudge the weight of their approach: heavy models raise data, GPU and maintenance costs, while overly light ones work in the demo and fail outside it. Finally, edge limits often surface late, when latency, connectivity or privacy rules turn out to forbid sending every frame to the cloud.

Each of these is far cheaper to discover on paper, or in a two-week experiment, than inside a finished build. That is the core argument for getting expert input at the start rather than after the first disappointing pilot.

Consider a weld inspection system trained on photographs taken in a quiet lab. On the production line, spatter clouds the lens, each part arrives at a slightly different angle and the lighting changes with every shift. None of this appears in the demo, yet all of it decides whether the system earns its keep.

What Early Expert Advice Should Cover

A good advisory engagement mirrors the real project in miniature and ends in decisions rather than slides. Look for these building blocks:

• Feasibility assessment. Tests whether the problem is solvable on your own data and in your own environment. The output should be a written verdict with an expected accuracy range and the main risks.
• Technology comparison. Weighs model families such as YOLO-style detectors, RT-DETR or Segment Anything against your limits on speed, hardware and labeling effort.
• Architecture design. Specifies cameras, lighting, compute, data pipelines and the edge-versus-cloud split in a blueprint a team can build from.
• Data and model audit. Reviews label quality, class balance, evaluation methods and drift, then recommends better labeling, synthetic data or a different model.
• Proof of concept. Produces a working prototype on your data, so accuracy is measured rather than projected.
• Deployment planning. Covers optimization such as pruning and quantization, hardware selection, and monitoring and retraining after launch.

Notice how much of this list has nothing to do with training. Optics, sensors and data discipline sit beside model choice, because a system fails at its weakest link.

This breadth explains why generalist AI teams sometimes struggle. They may have excellent modeling skills and still lack the experience to specify a lens, choose a lighting geometry or judge whether a depth sensor beats a second camera. Advice from people who have solved those problems before closes that gap quickly.

A Realistic Timeline

Good advice does not require a long commitment. A staged path keeps each decision small and informed.

It usually begins with a consultation of a few days to frame the problem, check for obvious blockers and agree what evidence is needed. Next comes a research sprint of about two weeks, which runs experiments on sample data and produces a technical report, a concept architecture and a priced roadmap. Only then does it make sense to commit to a proof of concept of two to three months, where a working demonstration is built on real data and measured against agreed targets.

The best engagements tell you the timeline and cost of the next step before it starts, and they price the remaining project before you commit to it. Providers such as It-Jim structure their offer this way and say an estimate follows within a day of receiving a task description. The point is not the specific numbers but the principle: every stage should end with enough evidence to continue, change direction or stop. For a startup, that discipline protects a small budget; for a large manufacturer, it keeps one disappointing site pilot from becoming a company-wide rollout built on shaky assumptions.

When to Bring in an Advisor

The timing matters almost as much as the quality of the advice.

The most common moment is before you commit a budget, to test whether the idea is feasible at all. Another is after a pilot underperforms and nobody can say whether the cause is data, hardware or approach. Advice also pays off when you are choosing between vendors or deciding whether to build or buy, and when you are moving a cloud prototype to edge hardware such as a Jetson module or a smartphone.

In each case the question is the same: what is the cheapest way to learn the truth about this project? An outside specialist with experience across many deployments recognizes failure patterns quickly, and has no stake in defending earlier design choices.

Questions to Ask Before You Hire

Not every advisor is equally useful. Put these questions to any candidate:

• Are you vendor-neutral, with no licenses or hardware to sell me?
• Will the deliverable be a written verdict with an accuracy range, rather than a general opinion?
• Will you tell me if the project should not be built?
• Do experiments run on my data instead of public benchmarks?
• Are estimates fixed, and are there small entry points?
• Who owns the code and models if I proceed to development?

Willingness to say no is the best single signal. An advisor who finds every idea feasible is selling a build, not advice. Equally, check that the team has hands-on production experience and the academic depth to handle unusual problems such as 3D reconstruction, pose estimation or specialized sensors, not just a slide deck of case studies.

Conclusion

Computer vision seldom fails for exotic reasons. It fails because cameras, data, accuracy targets and deployment limits were never tested against reality. A short, structured advisory phase turns those unknowns into numbers while changing course is still inexpensive, and it gives you a clear verdict on whether to build, adjust the approach or stop. Treat it as insurance for the larger investment: spend days and weeks answering questions before you spend months writing code.