Computer Vision Development Services: A Buyer's Guide to Systems That Survive Production

Computer vision development services are engineering engagements that turn images or video into a decision a business system can act on: counting stock, reading a shipping label, flagging a weld defect, confirming a parcel was delivered. The buying problem is not finding a vendor who can show you a working model. Almost anyone can. It is that computer vision has the widest gap of any applied AI field between a demo on a curated folder of images and a system that still works eighteen months later, on a dirty lens, in December light, at a site nobody trained on.

This guide is for the person signing the statement of work: what to ask for, what to refuse, and the five decisions that determine whether the project ships.

What computer vision development services cover

The label covers a pipeline, not a model. A real engagement includes camera specification, data collection, annotation and quality control on that annotation, model selection and training, packaging for the target hardware, integration with whatever consumes the output, and a monitoring loop that tells you when accuracy slips. Training is often the shortest part.

Almost every commercial brief reduces to one of seven task types. Naming the right one early is the highest-leverage decision in the project, because each implies a different annotation cost, a different hardware profile and a different definition of "correct".

The mistake we see most often is a brief asking for segmentation when detection would have answered the question. If the decision is "is there a crack", a box is enough. If it is "is the crack longer than 40 millimetres", you need pixels, and you have just multiplied the annotation budget. Push every requirement back to the decision it feeds. That discipline applies across custom machine learning development services generally, but vision punishes over-specification harder because labelling cost scales with label precision.

Cloud or edge: what actually drives the decision

Edge deployment means the model runs on hardware at the site: a small GPU module, an industrial PC, a camera with an onboard accelerator, a phone. Cloud deployment means frames travel to a server and a result comes back. This is an architecture decision, not a preference, and five variables decide it.

The trap is unit economics at scale. Cloud inference looks cheap with two cameras and becomes the dominant line item at two hundred. Do the arithmetic yourself before committing: frames per second you genuinely need, times operating hours, times cameras, times your provider's published rate. Check that rate on the day you buy rather than trusting a proposal. Most video use cases do not need every frame; dropping to two or five frames per second, or running a cheap motion trigger ahead of the expensive model, moves the economics more than any model optimisation will.

For multi-site video, a hybrid split is usually right. A small detector at the edge decides what is interesting, and only those crops go to the cloud for the heavier model, audit storage and retraining data. You get edge latency, cloud flexibility and a predictable bandwidth bill.

Why labelling dominates the budget

On most vision projects the architecture is a solved problem and the dataset is the entire advantage. Expect data work to take the largest share of budget and calendar. That is not a planning failure. It is what the work is.

Three costs hide inside "labelling". Collection: getting cameras onto the real site, in real lighting, with the real product mix, running long enough to catch rare cases. Annotation itself. And annotation quality control, which most proposals ignore: a second pass, an adjudication process, and a written guideline that settles edge cases before annotators invent their own answers.

Split that test set by site, day or camera rather than randomly. Random splits leak near-duplicate frames across the divide and inflate your numbers, which is how a model that scores 97% in review fails on its first new line.

What breaks vision systems in the field

This is the part vendors leave out. A vision model is a function of pixels, so anything that changes the pixels without changing the ground truth is a threat. Here is what actually causes post-launch accuracy collapse, roughly in order of frequency.

• Lighting change. The biggest single cause. A model trained on the day shift under skylights meets a different world at night under sodium lamps, and seasonal sun angle walks shadows across a conveyor over months. Fix it at the camera with controlled lighting before trying to fix it in the model.
• Camera placement drift. Someone bumps the mount during maintenance, or a replacement goes back a few degrees off. Small angle shifts change scale and perspective enough to break a detector tuned to a fixed view. Mount rigidly, store a reference frame, and alert when the live view diverges from it.
• Dirty lenses. Dust, condensation, oil mist, spider webs. Accuracy degrades gradually rather than failing loudly, which is worse, because the numbers are wrong for weeks before anyone notices. Put a blur and contrast check in the pipeline and raise a cleaning ticket automatically.
• Occlusion. Overlapping objects, pallets stacked in front of the lens, a worker standing in frame. Detection degrades and tracking degrades further, because identities swap when objects cross.
• Domain shift between sites. The model trained at site A meets different flooring, fixtures, uniforms and packaging at site B. Budget a per-site fine-tune and validation pass rather than assuming one model covers the estate.
• Product and process change. New packaging, a supplier change in material colour, a new SKU. The world moved and the training set did not, which is why monitoring and retraining belong in the original scope.

The consequence is that a vision project should be scoped as an ongoing system with a retraining budget, the same way you scope any deep learning development services engagement that touches the physical world. A fixed-price build-and-walk-away contract with no monitoring is a contract to deliver a model that quietly stops working.

Where foundation models replaced custom training

Multimodal foundation models, the large models that accept images alongside text, have genuinely changed parts of this field. Being honest about which parts separates a serious vendor from a hopeful one.

They have displaced custom training for document extraction and OCR on varied layouts, where you once trained a model per template and can now hand a general model an unseen invoice with the schema in the prompt. Also for open-vocabulary description and search, where you ask a question of an image without having trained a class for the answer, and for zero-shot triage before you commit to a labelled dataset. Point one at a hundred sample images and you learn in a day whether your problem is visually separable at all.

They have not displaced custom training where throughput and latency matter: a small detector answers in milliseconds at low power, and a large multimodal model cannot run per frame across a hundred cameras at a price anyone will pay. Nor for narrow expert judgements such as a hairline weld defect or a fabric flaw, because the general model has no concept of your defect taxonomy. Nor where you need calibrated confidence to drive a threshold, since a general model asked to be confident will usually oblige. The discipline that applies when you evaluate LLM development services applies here: test on your data, not the vendor's reel.

How to write accuracy into the contract

Precision is the share of the model's positive calls that were correct. Recall is the share of real positives it actually caught. They trade against each other along a confidence threshold, and a single "95% accurate" figure hides which one you got. On a line where one unit in a thousand is faulty, a model that calls everything good is 99.9% accurate and completely useless.

Specify both, at a named threshold, on a named test set. Then price the two error types, because that is what sets the threshold. What does it cost when the system flags something that was fine, and what does it cost when it misses something that was not? A false positive on a reject arm costs a good unit and an operator's minute. A false negative on a safety interlock costs something else entirely. If misses are expensive, tune for recall and accept the review load. If review labour is the constraint, tune for precision and accept that some cases slip.

Two more clauses are worth insisting on. An abstain path, so the system can say "I do not know" and route to a human, which beats a confident wrong answer and makes your precision target reachable. And ownership of the labelled dataset: the images and annotations you paid to create outlast the model architecture, the framework and probably the vendor. The contract should say they are yours.

Privacy, consent and India's DPDP Act

Anything pointed at people changes the compliance picture. Under India's Digital Personal Data Protection Act, 2023, images of identifiable individuals are personal data, so processing them needs a lawful basis, a stated purpose, notice to the people concerned, and retention limited to what that purpose requires. Facial images used to identify a specific person are more sensitive again, because identification is a materially different act from counting anonymous bodies in a frame.

The design responses are cheap to build in and expensive to retrofit. Process at the edge and transmit derived counts or events rather than raw footage. Blur or discard faces at capture when the use case does not need identity, which for footfall, queue length, dwell time and PPE compliance it does not. Put a hard retention clock on any raw video you keep and enforce it automatically. Post visible notice at the site, and keep a record of what is collected, why, who can access it and how long it lives.

Common questions

How long does a computer vision project take? Plan in three phases rather than one number. A feasibility pass on existing sample images can take days. A first production-ready model is usually months, and most of that is data collection and labelling rather than training. Multi-site rollout adds a per-site validation and fine-tuning cycle. Anyone promising a production vision system in a fortnight is describing a demo.

What is the difference between object detection and image segmentation? Object detection returns a rectangular box around each object with a class label and a confidence score, answering where something is and what it is. Segmentation returns a per-pixel mask, answering exactly which pixels belong to the object. Segmentation costs far more to annotate, so use it only when the business decision needs area, shape or precise boundaries.

Can I use a general AI model instead of training a custom one? For document extraction, OCR on varied layouts and open-ended image questions, often yes, and it is the sensible starting point. For high-frame-rate detection on fixed cameras, tight latency budgets, low-power edge hardware or subtle domain-specific defects, a small purpose-trained model still wins on cost, speed and reliability. Test both on your own images before committing.

How much labelled data do I need? It depends on task difficulty and class variety more than on any headline figure, so treat universal numbers with suspicion. The reliable method is empirical: label a stratified seed set, train, plot accuracy against dataset size, and see where the curve flattens. That curve tells you what further labelling is worth better than any rule of thumb.

Why did our vision model get worse after launch? Almost always an input change rather than a model change. Check lighting first, then camera position, then lens cleanliness, then whether the product, packaging or process changed. Compare a sample of recent frames against your training data visually before touching the model. This is why monitoring and a retraining budget belong in the original scope.

Do we have to keep the video footage? Usually not, and often you should not. If the value sits in the derived output, such as counts, events or extracted fields, keep that and delete raw frames on a schedule. Under India's DPDP Act, retaining personal data beyond the purpose it was collected for is a liability rather than an asset, and shorter retention also cuts storage cost.