The model is rarely the problem. The twelve steps around it are.

Computer vision fails between the notebook and the product: frame acquisition that blocks the UI thread, preprocessing built for a well-lit test set, a device-or-cloud decision nobody made, and no answer for the frame that returns nothing. We treat the pipeline, the latency budget and the failure behaviour as the deliverable, and the model as one replaceable component inside it.

FACT 01For an AI video tutor we prototyped on OpenCV alone, then benchmarked OpenCV + TensorFlow against OpenCV + MediaPipe. MediaPipe won on accuracy, stability and speed — and shipped behind a clean API for the rest of the stack.
FACT 02Acoustic, RF, EO/IR and radar fused into one validated track for airspace security — detection to handoff in four seconds.
FACT 03There is no accuracy percentage anywhere on this page. A number without a dataset, a threshold and an operating point means nothing — so every claim here is a runtime constraint you can check instead.
Spend one frame ↓

30 minutes, working session. You leave with a one-page constraint sheet either way. Nobody follows up more than once.

Where vision projects actually stall

Never at the part everyone worries about. These are the six we are called into.

ENVIRONMENT

It works on the researcher’s machine

A notebook, a good GPU, curated images, a number everyone is proud of. Then someone points a real phone at a real room and it falls apart — not the model, the twelve unglamorous steps around it that nobody owns.

LATENCY TAIL

It runs, but it stalls

Frames arrive faster than they are processed, the queue grows, the UI thread blocks, and the picture freezes for half a second exactly when the user moves. Average latency looks fine in the log. The tail is what people feel.

TOPOLOGY

Nobody decided device or cloud

So it does both, badly. A server means a round trip, a bill per frame and a conversation with legal. The device means model size, battery and heat. The decision was deferred, and now it is load-bearing.

UNSEEN INPUT

The camera sees something you never tested

A screen instead of a face. Glasses. Backlight from a window. A skin tone the training set under-represents. The system does not fail loudly — it returns a confident wrong answer, which is worse.

NO PATH OUT

The prototype cannot be released

No tests, because how do you unit-test a camera. No CI, because the pipeline needs a GPU. No versioning of the model separately from the code, so nobody can say which model produced last Tuesday’s output.

NO DATE

It became a permanent research project

Six months in, still a demo, still one person who understands it, still no date. The business wanted a feature with a release; what it has is an ongoing investigation.

A volumetric capture stage lit in magenta at Immerse Global Summit, with a performer standing at its centre
Where the next brief comes from

Time in the room with the hardware

A volumetric capture stage on the show floor at Immerse Global Summit, Miami Beach — somebody else’s rig, photographed by us. The capture hardware that looks like a novelty at a trade show is the input pipeline a client asks us to build against a year or two later: multi-camera geometry, depth, and a lot of frames arriving faster than anyone budgeted for. More about how we work →

Four pipelines that met a real room

Each links to its own case page. Every fact below is a constraint, not a score.

AI VIDEO AGENT
LIVE TUTOR
OPENCV / MEDIAPIPE

Real-time face and head tracking for a live AI tutor

Distance and head-angle tracking behind an animated tutor that teaches children French in a browser — running alongside speech recognition, speech synthesis and a 3-D character on the same frame budget. The hard part is that budget: a stall here is not a bad metric, it is a child watching a teacher’s face freeze. We prototyped on OpenCV alone, benchmarked OpenCV + TensorFlow against OpenCV + MediaPipe, and shipped the winner behind a clean API.

MEASURED, NOT GUESSED — THREE PIPELINES BENCHMARKED HEAD TO HEAD

PANOPTESAI
AIRSPACE SECURITY
SENSOR FUSION

Four sensor types, one validated track

Acoustic, RF, electro-optical/infrared and radar fused into a single track an operator can act on. The hard part is that each sensor lies differently — its own false-positive personality, its own latency, its own confidence semantics — and a naive fusion inherits the union of everyone’s errors instead of the intersection of their agreement.

DETECTION TO HANDOFF IN 4 SECONDS

NETWORKING APP
ON A PHONE
FLUTTER / OFFLINE

Face recognition on whatever phone the user owns

A Flutter app that turns a selfie taken at an event into an enriched contact, with AI follow-ups, CRM export and an offline mode. The hard part is that it runs on unknown hardware in an unknown room, and the venue Wi-Fi is usually the first thing to fail — so the capture path has to behave when the network is gone and reconcile later.

SURGICAL VR
IMAGING → GEOMETRY
RENDER PIPELINE

Interactive 3-D patients from standard medical images

An imaging-to-geometry pipeline that turns flat, static medical images into interactive 3-D representations a surgeon can explore in VR, for rehearsal and training. The hard part is that fidelity here is a functional requirement, not an aesthetic one, and it has to hold at a frame rate that keeps VR comfortable. Training and rehearsal software — not a diagnostic device.

Tell us what the camera has to understand, on what hardware, at what latency. We will tell you which of the three is the binding constraint.
A face-landmark mesh drawn as fine green lines against black — the perception layer built for an animated AI tutor
Landmark mesh — AI video agentLandmarks tracked live, stable enough that a 3-D character can follow a child’s head while speech recognition and synthesis share the same frame budget. Face-tracking case →

You get one frame. Here is where it goes.

A vision feature does not have a speed, it has a budget: at 30fps every stage of the pipeline shares 33 milliseconds. Pick the hardware, drag the target frame rate, and watch which stage runs out of room first — because that stage, not the model, is usually what you fix.

SCHEMATIC MODEL — REPRESENTATIVE STAGE COSTS, NOT A BENCHMARK OF ANY DEVICE WITHIN BUDGET
ONE FRAME, STAGE BY STAGE
One frame divided into pipeline stages, measured against the frame budget BUDGET anything past the dashed line is a frame the user does not get
READOUT
TARGET30 fps
FRAME BUDGET33.3 ms
PIPELINE COST30.5 ms
ACHIEVED30 fps
FRAMES DROPPED0 / s

Everything fits. This is the only state in which a demo and a product behave the same way.

This is the conversation we have in the first week rather than the sixth month. Quantising to int8, letterboxing once instead of twice, asking the camera for the pixel format the model already wants, capping candidates before non-maximum suppression, moving the overlay off the main thread — each is worth milliseconds, and the profile says which one you are allowed to skip.

On the device or on a server — the decision that sets your business model

It belongs in week one, with measurements attached, because it decides cost per inference, what your privacy policy can say, and whether the feature works on a train.

 On the deviceOn a server
CostPaid once at build time. Zero marginal cost per frame.A bill per frame, forever, that scales with your success.
PrivacyThe image never leaves the phone — usually the shortest conversation with legal.Images in transit and at rest, retention policy, a region decision, a processor agreement.
LatencyNo round trip. The budget is entirely yours to spend.Add the network twice, plus whatever the tail of your worst connection looks like.
Model sizeQuantised, pruned, converted — and you pay for it somewhere in the tail.Whatever fits on the GPU you rent. Swap it without shipping an app release.
Sustained useThermal throttling after a few minutes is real, and it is where most mobile demos quietly stop being real.Constant, until the queue behind it is not.
No networkStill works. For a venue, a warehouse or a field, this is often the whole argument.Does not. Needs an offline story regardless.
RuntimesCore ML on iOS, NNAPI on Android, ONNX Runtime where a single graph has to serve both.ONNX Runtime or TensorRT on the GPU, batching tuned for throughput rather than latency.

Most products end up split: a small model on the device for the live loop, a larger one on a server for the frames that matter. The fallback between them is a design decision, not an accident.

Field test — video

Outdoors, where the sensors disagree

The fusion system under test against real drones. A bench proves a model; a field test proves a pipeline — the false positives each sensor invents, the latency each one adds, and the four seconds from detection to handoff. PanoptesAI case →

The work, as we actually sell it

Timelines are indicative ranges and depend on scope.

Feasibility read, in writing

1–2 WEEKS

Whether what you want is possible at your latency, on your target hardware, at your cost per inference — and what would have to change if it is not. You get the verdict, the constraint table, and a document you can hand to another team.

Prototype to production pipeline

6–12 WEEKS

Capture, preprocessing, inference, post-processing, fallback, telemetry. You get the pipeline, a latency profile with the tail visible, and the model versioned separately from the code.

On-device inference and mobile vision

4–10 WEEKS

Model conversion and quantisation, Core ML and NNAPI paths, thermal and battery behaviour under sustained use. You get the on-device path, the measured cost in heat and battery, and a documented cloud fallback.

Tracking, landmarks and pose

4–10 WEEKS

Face mesh, head pose, gaze approximation, multi-object tracking with re-identification after occlusion — and landmark stability, which is what separates a usable overlay from a twitching one.

Multi-sensor fusion

10–20 WEEKS

Where more than one input has to agree before something is true: track association, confidence reconciliation, and one validated output rather than four opinions.

Vision inside a real product

WHY WE ARE CALLED

The part most vision specialists do not do: authentication, storage, billing, admin, releases — and a CI pipeline that has to run a job needing a GPU.

Two phone screens from the networking app: a captured selfie on the left and the enriched contact it produced on the right
On the device

Recognition on whatever phone the user owns

Capture, recognition and enrichment on unknown hardware in an unknown room — with an offline path, because the venue Wi-Fi is usually the first thing to fail. Mobile case →

What you are probably thinking

“You’re not a research lab.”
Correct, and you probably do not need one. Most stalled vision projects we see have an adequate model and no pipeline. If yours is genuinely a research problem, we will say so in the feasibility week, and you will not have spent a quarter finding out.
“We already have an ML person.”
Good — they should keep the model. We take the engineering around it: capture, latency, device paths, fallbacks, tests, release. That division is the one that works, and we write it down before we start so nobody is defending territory in month two.
“How accurate is it?”
We will not answer that in a marketing sentence, because an accuracy number without a dataset, a threshold and an operating point is meaningless. What you get instead is a measured latency profile on your target hardware and an honest account of where the pipeline is weakest.
“Can it run on-device?”
Often — and since the answer changes the business model, it belongs in week one rather than month six. Model size, quantisation loss, thermal behaviour under sustained use and the cloud fallback all get decided together, with the measurements attached.
“We tried an outside dev shop and it went badly.”
Usually the same three causes: no senior person accountable, a demo-grade codebase, and a handover that never happened. Here you get direct access to the engineers doing the work, no account-manager layer, a senior architect signing off every project, and tests and documentation as part of the deliverable rather than a phase that gets cut.
“This will take a year.”
It will not, because we do not start with a year-long thing. The first engagement is a feasibility read with a date on it, and it ends in a document you keep whatever you decide.
A Fluvius engineer wearing a backpack-mounted 3-D capture rig on the show floor at Immerse Global Summit

The record behind the pages

200+
Clients served
10+
Years of happy clients
7+
Years our longest clients have stayed

Many of our clients have been with us for 7+ years straight. The Upwork and Clutch records are independently verifiable.

Not ready to talk? Take the checklist.

One page, 14 questions to answer before you productionise a vision model — the latency tail rather than the average, cost per inference on the device against a server, thermal behaviour under sustained use, what happens below your confidence threshold, whether the model is versioned separately from the code, and the edge cases nobody has pointed a camera at yet.

Tell us what the camera has to understand, and on what.

A free 30-minute working session, not a sales call. Bring the thing you want recognised, the hardware it has to run on and the latency you can tolerate; we tell you which of the three is the binding constraint. You keep a one-page constraint sheet either way — target hardware, achievable frame budget, a device-or-cloud recommendation, and the failure cases we would test first.

RELATED SERVICES → 3D, Animation & Computer Vision IoT & Edge AI Video AI Agents Hardware & IoT Lab All services