What it takes to build a production-ready computer vision system

01.1. Data: representative images

Your model learns from what it sees. If it only sees good conditions, it will only work in good conditions. You need images across lighting changes, camera angles, times of day, seasons, product variants and edge cases such as dirt on the lens or a partly blocked view.

A practical approach: spend the first stretch capturing footage over several days and shifts, not one afternoon. Include examples of the rare events you care about most. If defects are uncommon, plan to collect or stage more of them. A model trained on a thousand good parts and five bad ones will not learn much about bad.

02.2. Labelling: consistent, reviewed annotations

Labels are the model's teacher. If two labellers disagree on what counts as a scratch, the model learns confusion. Write down labelling rules with example images, including the borderline ones. Have a second person review a sample. Track agreement between labellers.

A frequent surprise is that domain experts disagree too. Quality staff at the same plant may draw the line differently. Better to find out in week three than after deployment. Settle the definition, then relabel.

03.3. Model: tested on unseen, real conditions

Keep a test set that the model never trains on, and make it reflect reality, including other days, other shifts and other cameras. Report results per condition, not a single score. A model that scores well overall but fails at night is not ready for a night shift.

Choose the simplest model that meets the target. Larger models cost more to run and are harder to fit onto edge hardware. Decide the trade-off between false alarms and misses with the business, because the right balance depends on what each costs.

04.4. Hardware: cameras, lighting and edge compute

The cheapest improvement is often not software. Fixed mounting, a stable light source, a clean lens and a shield against sunlight can do more than weeks of retraining. Decide early whether inference runs on the camera, on a gateway or on a server, based on latency, network reliability and data sensitivity.

Plan for heat, dust, vibration and power cuts. Decide what the system does when it fails. A safe default, such as falling back to manual checks and raising an alert, is part of the design.

05.5. Integration: alerts, rejects, dashboards

A detection is only useful when something happens. That might be a reject signal to a PLC, a message to a supervisor, or a number on a dashboard. Integration work is often underestimated. It involves agreeing signals, handling timing, logging each decision and making the output understandable to the people using it.

Show the evidence. An alert with the image attached is trusted far more than a bare "defect detected".

06.6. Monitoring: detect drift when conditions change

Things change. A new supplier, a repainted wall, a moved camera or a seasonal light shift can reduce accuracy without any error message. Monitor image brightness, detection rates and the share of low-confidence results. Keep a stream of recent samples for human review. Set a schedule for retraining and a rule for when to trigger it early.

07.What a bad launch looks like

A typical bad launch goes like this. The team trains on two weeks of footage taken in summer. The model scores well on a held-out slice from the same two weeks. It goes live. In the first winter month, the sun sits lower and the afternoon glare changes. Accuracy falls, operators lose trust, and they start ignoring alerts. Six weeks later nobody remembers who owns the system. The model was never the problem. The data covered one season, the test set came from the same period, and no one watched the live numbers.

08.Deciding what "good enough" means

Before building, agree two numbers with the business. First, how many true problems must the system catch. Second, how many false alarms the people downstream can tolerate. These pull against each other. Raise the threshold and you miss more. Lower it and operators drown in alerts. The right setting depends on cost: a missed safety event is not the same as an extra look at a good part. Write down the trade-off and the threshold, and review it after the first month with real data.

09.Shadow mode

Shadow mode means the system makes calls but triggers nothing. People keep working as normal, and you compare. It is the cheapest way to find the problems that testing missed, such as odd lighting, a camera that vibrates or a product variant nobody mentioned. Run it long enough to cover different shifts, products and weather. Treat each disagreement as information: sometimes the model is wrong, and sometimes the person was.

10.Who owns it afterwards

Systems drift towards neglect when ownership is unclear. Name one owner on the business side, who cares about the outcome, and one on the technical side, who can retrain and fix. Give them a monthly slot to review alert rates, sample errors and planned changes in the plant or store. Add a rule that any change to products, packaging, layout or camera position is reported to them first.

11.A short pre-launch checklist

• Success criteria and a test method agreed in writing.
• Test results reported per condition.
• Labelling rules documented.
• Failure behaviour defined and tested.
• Alert owners named.
• Monitoring and retraining plan in place.

12.Costs people forget

Budget conversations focus on development. Production adds ongoing costs: replacing and cleaning cameras, updating edge devices, storing a sample of images for review, labelling new data, and staff time to look at alerts. None is large alone. Together they decide whether a system remains useful in year two. Ask for them in the plan, so the owner is not surprised.

13.Security and access

Cameras and edge devices sit on your network, so treat them like any other system. Change default passwords, keep firmware updated, separate the camera network from the office network and limit who can view footage. Log access. If footage includes people, keep retention short and define who may export it. A vision system that creates a security hole will lose support quickly.

14.Handling the rare case

Rare events cause the most trouble. If a defect appears once in thousands of parts, your dataset holds few examples and the model may miss it. Options include staging defects on purpose, collecting from older stock, or flagging anything that looks unusual compared with normal parts and sending it for review. Be open with the business that rare events will be caught less reliably, and design a human check around them.

15.Common mistakes

• Judging the system on a demo clip.
• Treating lighting as someone else's problem.
• Skipping shadow mode before going live.
• Having no owner for alerts.
• Assuming the model stays accurate forever.

16.What to do next

If you have a pilot that is stuck, check the order above. Most teams find the problem in the first two items. If you are about to start, budget time for data and site work, not just model training.

Brandsmashers has built vision systems through all six stages, and we can review your current approach and point out where it is likely to break.