Computer Vision
Computer vision is the use of models to interpret images and video — detecting defects, counting objects, reading documents, recognising conditions, tracking movement. We build two broad kinds of system: inspection and detection on production lines and sites, and extraction from documents and images that currently get read and retyped by people. Both are built against real operating conditions rather than the clean samples a pilot is usually shown.
The problem
Two situations, one root cause
The late shift catches fewer
On an inspection line: the same criteria, the same product, measurably different results at hour seven than at hour one. Nobody is at fault — sustained visual attention degrades, and it degrades first on the subtle defects that matter most. The inconsistency stays invisible until a batch reaches a customer.
Someone is retyping documents into a system all day
Invoices, delivery notes, claim forms, application packets, identity documents. The keying is slow and it is not the expensive part — the expensive part is that a transposed figure looks exactly like a correct one, so the error rate is unmeasured until something fails reconciliation weeks later and nobody can say how long it had been happening.
It worked on the samples
Shared by both, and the most common reason a pilot does not survive contact with production. The trial ran on inputs someone chose: well-lit photographs taken straight on, or clean PDFs exported directly from a system. Production sends frames from a camera bolted where it fit behind a housing nobody cleans, and documents that were printed, signed, scanned at an angle, and forwarded as a photograph taken on a phone.
What a real fix takes
The input decides more than the model does. On a line that means the mount, the lighting and the trigger timing; on documents it means what you accept at intake and what you reject rather than silently misread. Fixing capture routinely beats weeks of modelling and costs a fraction of it — and in neither case is it what anyone hopes to be told. Two further things decide the outcome and neither demonstrates well: this is a dataset project before it is a modelling project, so wherever two annotators apply different definitions that disagreement becomes your accuracy ceiling; and for extraction specifically, what matters most is the behaviour when the model is confident and wrong, because an unchecked misread does not look like an error, it looks like data.
Outcomes
What changes
Inspection at a rate and consistency people cannot sustain
Every item checked by identical criteria, continuously, with a record of the judgement and the image it was made from.
Documents processed without keying
Printed and handwritten records turned into structured data, with validation that catches misreads before they enter your systems rather than after.
Detection of things that are easy to miss
Small defects, subtle changes over time, events in footage nobody has time to watch, and fields buried in documents nobody reads end to end.
An honest read on your inputs
Frequently the highest-value output of early work is the finding that your cameras, lighting or document intake need to change before any model will perform. Better to hear that in week two than after a build.
What we build
What we build
Defect and quality inspection
for production lines, tuned to your tolerance for false positives versus missed defects — a business tradeoff we make explicit rather than optimising toward a single accuracy number.
Document and form extraction
covering printed and handwritten text, layout analysis, tables, checkboxes and signature presence, and multi-page documents where a field's meaning depends on which page it appears on. The everyday work is rarely one clean template; it is forty variants of a form and a long tail of suppliers who each format their own.
Validation and confidence routing
The half of an extraction system that decides whether it is safe to use: cross-field checks that catch what a per-field confidence score cannot — do the line items sum to the stated total, is the date inside a plausible range, does the reference exist in your own records — and a threshold above which a person reviews it. A confident misread is worse than a refusal, so the system is built to be able to refuse.
Object detection and counting
for inventory, footfall, vehicles and assets.
Video analytics
for safety compliance, process monitoring and event detection, with the privacy controls that use case demands.
Condition and change monitoring
across time-series imagery, for infrastructure, agriculture and site progress.
Annotation pipeline and dataset management
The labelling workflow, the written annotation standard, inter-annotator agreement checks and versioning — because two people applying different definitions of "defect", or disagreeing on which of two dates is the invoice date, will cap accuracy below anything the model could otherwise reach.
Coverage strategy for the rare case
How examples of what you actually care about get gathered: staged failures and historical footage review where a defect occurs a few times a month, or deliberate collection of the unusual layouts where a document type has a long tail. Planned explicitly rather than hoped for.
What you receive
Three things you keep
The labelled dataset and its held-out set
Your images or documents, annotated to a written standard, versioned, with a test set that deliberately includes the difficult cases rather than a random sample. This is the asset. Models get replaced — architectures improve and retraining on a good dataset is cheap — but a well-built dataset carries forward to whatever comes next, and it is portable to any vendor, including one that is not us.
The capture specification
For a line: camera, lens, mounting position, lighting, trigger timing, and the tolerance each has before performance degrades. For documents: minimum resolution, accepted formats, what a usable input looks like, and what gets rejected at intake instead of processed badly. Written down, so that when somebody fits a different bulb or a supplier redesigns their invoice template, there is a document that explains why the numbers moved.
The threshold and routing rule, recorded
Where you sit between missed defects and false alarms, or between an extraction accepted automatically and one sent to a person — what each kind of error actually costs you, who chose that point, and when it should be revisited. These systems get presented as an accuracy number; they are really a business tradeoff, and writing down who owns it stops it being quietly re-set by whoever is most annoyed by the alerts this week.
How it works
How it works
- Week 1
Input assessment
We examine what production actually produces: real footage under real line conditions, or a real sample of documents including the poor ones — the scanned, the photographed, the ones from the supplier who changed their template. This determines feasibility more than anything else, and it is where we most often recommend fixing capture or intake first.
- Weeks 2–4
Dataset construction
Collection, annotation to a written standard, quality review, and building a held-out set that includes the hard cases rather than a convenient sample.
- Weeks 4–6
Modelling
Starting with pre-trained architectures fine-tuned on your data. Training from scratch is rarely justified. Evaluated against realistic conditions, not a clean subset.
- Weeks 6–8
Deployment and integration
Edge or cloud depending on latency and connectivity, model optimisation where running on-device, and — for extraction — the validation rules and the review queue for anything below threshold.
- Weeks 8–10
Field validation
Real conditions, real operators, failure collection. These systems consistently meet situations absent from the training set, and this phase is where they surface.
Ongoing
Monitoring, periodic retraining as products, conditions and document formats change.
The phase that surprises clients is dataset construction, though for different reasons depending on which system you are building. On a line, where the target condition occurs a handful of times a month, gathering enough examples can add weeks that no amount of engineering compresses — you are waiting on the world. In document work, the surprise is the long tail: the first eighty layouts are straightforward and the remainder each need their own handling. We identify which of the two you are facing in week one, so it is a plan rather than a delay.
Technology
What we work with
Technologies we work with, selected against your imagery, your latency budget and the hardware you actually have. Not an exclusive stack — in this field the right answer changes with the problem more than in most.
Models: YOLO family for detection, segmentation architectures where boundaries matter, vision transformers where the problem justifies them, and increasingly multimodal models for document and scene understanding — which have made a category of previously custom work straightforward.
Documents: layout-aware extraction combining traditional OCR with vision-language models, validated against structural and cross-field rules rather than trusted on confidence alone.
Deployment: NVIDIA Jetson or comparable edge hardware where latency or connectivity requires local inference; cloud inference where it does not. Quantisation and pruning to fit the hardware you actually have.
Annotation: CVAT, Label Studio or similar, with review workflow and inter-annotator agreement checks.
Where this applies
Where this applies
Strongest in two places. For inspection and detection: manufacturing lines and site monitoring, where the task is repetitive, high volume, and currently done by people whose attention degrades across a shift. For extraction: document-heavy operations in fintech, healthcare, logistics and supply chain, legal and professional services and real estate, where the volume of forms and records exceeds what keying can keep up with.
Weakest where conditions vary wildly between sites, where examples of the target condition are extremely scarce and cannot be staged, or where every document is genuinely bespoke rather than a variation on a form. It is also a poor fit where the required accuracy leaves no room for human review at all — if a missed case is catastrophic and unreviewable, vision is an assistive layer rather than a replacement, and we will scope it that way.
Why us
One team, not three vendors
The usual way
- A strategy consultant, a development shop and a marketing agency, each scoped separately.
- Months spent getting three vendors to agree, and blame to allocate when something breaks.
- The model ships and adoption becomes somebody else's problem.
With Nexiour
- One team across strategy, engineering and growth. You skip the coordination tax entirely.
- We own the whole outcome — from the first audit to the system that is running.
- Delivery across the UK, UAE, Germany and India, with overlapping hours in four markets.
What it costs
How we scope and price
Fixed scope, quoted after an input assessment. These projects vary more in cost than any other category we work in, which is why we assess before quoting. Three things drive it.
Whether usable annotated data exists
An existing labelled set makes this a modest engagement. Building one from scratch, to a consistent standard, frequently dominates the budget.
How much variation the inputs carry
On a line, a rare target condition is a collection problem measured in calendar time as much as effort. In documents, a long tail of layouts and suppliers is the same problem wearing different clothes.
Deployment target and integration depth
On-device inference adds hardware selection, optimisation and physical installation constraints. Extraction that writes into a system of record adds validation, reconciliation and a review queue that cloud inference alone does not.
FAQ
Frequently asked questions
For fine-tuning a pre-trained model on a well-defined task, often several hundred to a few thousand per class — but the number matters less than coverage of real variation. A thousand images from one lighting condition is worse than three hundred across all of them, and the same is true of three hundred invoices from one supplier.
Often, and the assessment tells you. Where it cannot, the fix is usually cheaper than people expect — better lighting or a changed angle frequently outperforms a better model, and costs a fraction of one.
Sometimes, and the honest answer depends on your actual documents rather than the general capability. Consistent handwriting in defined boxes is usually workable. Free-form handwriting across a whole page varies widely, and we would want to see a real sample before committing to it either way.
This is designed rather than hoped about. Cross-field validation catches a class of errors that per-field confidence does not, anything below threshold routes to a person, and the system is built to be able to refuse rather than always produce an answer. An unchecked misread enters your records looking like data, which is why the refusal path matters more than the headline accuracy.
When the condition you want detected happens rarely and cannot be staged or found in historical material — you will spend the budget waiting for examples. When imaging conditions differ so much between sites, or documents so much between sources, that each needs its own dataset, which multiplies cost rather than adding to it. And when the accuracy bar leaves no room for review, because no vision system is perfect and a process with nowhere to put uncertain cases will reject it.
No. Edge deployment is standard where latency, bandwidth or privacy requires it, and modern edge hardware handles most inspection workloads comfortably. Document extraction is more often cloud or on-premise server work, driven by where the documents already live.
Determined by your inputs and the difficulty of the distinction, so we assess before quoting a figure. We also frame it as the tradeoff it really is: catching more defects means more false alarms, and accepting more extractions automatically means reviewing fewer and catching fewer mistakes. Where you sit on that curve is your decision.
By design: on-device processing where possible, face and identity blurring, retention limits, and processing only what the use case requires. In many jurisdictions this is a legal requirement rather than good practice, and it shapes the architecture from the start.
Performance degrades and monitoring flags it. Retraining on new examples is routine and planned for, not an emergency — and because you own the dataset, it is cheap.
Related