Capability
Detection, inspection and counting from camera feeds — trained on your footage and your failure cases, deployed to the hardware on your floor, and reported with an accuracy and false-positive rate you can hold us to.
From $9,000 · 6–10 weeks · fixed scope, agreed in writing
What your team gets
Not a strategy deck. A running system, the permissions around it, and the code in your repository.
What we build
All of them share one thing: a camera already sees the answer, and nobody has time to watch the screen.
Catching the fault on the line rather than at the customer. Trained on the specific defects you actually see, which is why generic models do not work here.
Surface defects on packaging, flagged before the pallet is wrapped.
Counting objects that are tedious, error-prone or unsafe for a person to count repeatedly.
Cartons on a pallet verified against the delivery note before it leaves the dock.
Confirming that something required is there — a label, a seal, a piece of protective equipment — and raising it when it is not.
Missing batch label detected before the case is sealed.
Turning photographed or scanned documents into structured records, with a confidence threshold below which a person checks.
Delivery notes photographed on a phone, read into the ERP.
Reading serials, batch codes and meter readings from imperfect real-world images — angled, dirty, badly lit.
Container numbers read from a gate camera in the rain.
Detecting when something enters a place it should not, or stops moving when it should be moving.
A stationary forklift in a walkway, raised within seconds.
How we build it
Computer vision projects fail on data and deployment far more often than on modelling. The model is usually a solved problem; the labelled dataset and the box on the wall are not. These five steps put the effort where it actually decides the outcome.
Footage from your cameras, in your lighting, at your angles. A model trained on clean stock imagery falls apart against a dusty lens and a backlit doorway, and there is no way around collecting the real thing.
A labelling schema agreed with the people who know what a defect is, then consistent annotation with review. Most accuracy problems are labelling problems wearing a disguise.
Start from a pre-trained detector and fine-tune on your classes, with augmentation matched to real variation — lighting, angle, occlusion, motion blur — rather than to whatever the library does by default.
Precision and recall on a held-out set drawn from different days and shifts, with the confidence threshold chosen deliberately: a false alarm and a missed defect rarely cost the same, and the threshold should reflect which one hurts.
Export to ONNX or TensorRT and run on hardware at the edge, so inference does not depend on a stable connection to a cloud region. Monitoring watches for drift when the line, the product or the season changes.
Less than most people fear, and more of the rare case than anyone expects. A few hundred well-labelled examples per class is often enough for a first useful model; the constraint is almost always the defect that occurs twice a week, not the one that occurs constantly. We plan collection around the rare cases from the start, because they are the ones the model is being bought to catch.
Inference runs on site by default. A camera feed to the cloud costs bandwidth continuously, adds latency to a decision that may need to be immediate, and stops working when the connection does. A Jetson-class device or an industrial PC handles most detection workloads comfortably; the cloud is where training and retraining happen.
A model trained in winter meets different light in summer. A new supplier changes the packaging. Accuracy decays quietly, which is the dangerous part. We ship with sampled frames retained for review and a retraining pipeline your team can run, so the second version does not require starting over.
Where it lands
Surface and assembly defects caught on the line rather than at the customer.
Carton counts and label checks verified at the dock before a pallet leaves.
Grading and count from field or packhouse imagery, without a person on the belt.
Batch and expiry codes read from packaging, with every low-confidence read checked.
Material classification at the sorting point, feeding the counts a report needs.
Pick verification before dispatch, cutting the returns caused by the wrong item shipped.
Technology
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
How the engagement runs
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
What the camera sees today, what decision the detection would drive, and whether anyone would act on it. Half of computer vision requests do not survive that last question, and it is better asked now.
A look at real footage, a labelling schema agreed with the people who know what a fault is, and an honest assessment of whether the camera position can support the task at all.
Collection, annotation with review, and a first fine-tuned detector measured on a held-out set from different days.
Augmentation matched to real variation, error analysis on the cases that matter, and a confidence threshold chosen against the real cost of a false alarm versus a miss.
Export, deployment to on-site hardware, the alert path wired to someone who can act, and a retraining pipeline your team can run.
Why Devs Core
A model tuned on someone else’s clean images will not survive your lighting, your angles or your dust.
Labelled data outlives any model. You keep it, and it is what makes the second version cheap.
Inference on site, so a dropped connection does not stop detection and video does not leave the building continuously.
Precision and recall on a held-out set, with the threshold chosen against what a false alarm actually costs you.
Sampled frames retained and a retraining pipeline handed over, because accuracy decays quietly and silently is the worst way to find out.
Some tasks need a different angle, better light, or a sensor rather than a camera. Hearing that in week one is cheaper than proving it in week nine.
Questions
Computer vision development is building software that interprets images or video to make a decision — detecting an object, finding a defect, counting items, or reading text from a photograph. In practice the work is collecting representative footage, labelling it consistently, fine-tuning a detection model on those classes, and deploying it to hardware where the decision is needed.
Often a few hundred well-labelled examples per class for a first useful model. The real constraint is rare cases: the defect that happens twice a week is usually the one the system is being bought to catch, so collection is planned around it from the start rather than hoping enough examples turn up.
On site by default. Streaming video to the cloud costs bandwidth continuously, adds latency to decisions that may need to be immediate, and fails when the connection does. A Jetson-class device or industrial PC handles most detection workloads; the cloud is used for training and retraining.
Often yes, if they expose an RTSP or ONVIF stream and are positioned to see what matters at sufficient resolution. Camera position and lighting are assessed in the feasibility phase, because no amount of modelling rescues a camera that cannot see the thing it is being asked to judge.
That depends on the task and the data, which is why we measure rather than promise. We report precision and recall on a held-out set drawn from different days and shifts, and we set the confidence threshold against the real cost of a false alarm versus a missed detection — those rarely cost the same.
Computer vision development starts at $9,000 over six to ten weeks, for a fixed scope agreed in writing. The main variables are the number of classes, how much footage has to be collected and labelled, and whether on-site hardware is already in place.
Accuracy drifts, usually quietly. We ship with sampled frames retained for review and a retraining pipeline your team can run, so a new supplier’s packaging or a seasonal change in light means a retrain rather than a rebuild.
No. We work on objects, defects, counts, text and zones. Face recognition carries legal and ethical constraints that vary by jurisdiction and that we are not the right team to advise on.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com