Connor Patterson
Most organizations engaging a computer vision consultancy for the first time make the same mistake.
They scope the engagement around the deliverable ("we want a defect detection model" or "we need a document processing system") without thinking through the engagement model itself. How involved will the internal team be? What happens after delivery? Who owns the system when the consultancy leaves? What's the mechanism for improving performance over time?
These questions determine whether the engagement produces a capability or a dependency. Getting them right before signing anything is worth more than any feature comparison between consultancies.
The three engagement models worth understanding
Computer vision consultancy engagements take meaningfully different forms. The right model depends on what you're trying to build: a one-time system, an ongoing capability, or something in between.
Model 1: Project-based delivery
The consultancy scopes a defined project, delivers it, and exits. You get a working CV system. The consultancy gets paid. The engagement ends.
When it works: when the problem is well-defined and unlikely to evolve significantly. A document processing system for a standardized form type. A specific quality inspection system for a stable product line. Cases where the deliverable can be precisely specified upfront and where your internal team can maintain what's built.
When it fails: when the problem is more complex than initially understood. When the training data requirements turn out to be larger than estimated. When integration complexity with existing systems was underestimated. When the model degrades after six months and there's no one to call who understands why.
What to build into project-based contracts: a post-delivery support window, typically 60-90 days, where the consultancy remains available for questions, bug fixes, and unexpected production issues. Documentation requirements that make the system maintainable by someone who didn't build it. Performance SLAs that define what happens if accuracy falls below the promised threshold post-delivery.
Model 2: Retainer-based advisory
The consultancy provides ongoing guidance, architecture reviews, data strategy, evaluation framework design, and production troubleshooting, while your internal team handles most of the implementation.
When it works: when you have ML or engineering capability internally but lack CV-specific expertise. When you want to build internal competence rather than dependency. When the problem is evolving and you need access to expert judgment on an ongoing basis rather than a fixed deliverable.
When it fails: when the internal team doesn't have sufficient ML foundation to act on expert guidance effectively. When the problem requires more hands-on engineering than advisory support can provide. When the retainer gets deprioritized in favor of other work and the advisory relationship becomes nominal.
What to build into retainer contracts: a clear definition of what the retainer includes, hours per month, response time commitments, and what types of questions and reviews are covered. A review cadence that prevents the relationship from becoming inactive. Clear escalation paths from advisory to implementation support if the internal team hits a wall.
Model 3: Embedded team engagement
The consultancy places experienced CV engineers within your team for a defined period, working alongside internal staff on the production system while explicitly building internal capability.
When it works: when you're building a CV capability for the first time and want to develop internal ownership alongside external expertise. When the problem is complex enough to require sustained engineering effort but you want the capability to be internally owned over time. When knowledge transfer is a primary objective alongside delivery.
When it fails: when the embedded engineers operate as a separate unit rather than genuinely working with internal staff. When the knowledge transfer is treated as documentation at the end rather than collaborative work throughout. When the engagement ends before internal engineers have reached the competence level required to own the system.
What to build into embedded contracts: explicit pairing requirements, internal engineers working alongside consultancy engineers on each component, not receiving finished deliverables. Milestone-based competence targets for internal team members. A defined transition plan that specifies what internal ownership looks like and when the embedded team steps back.
What good computer vision consultancy discovery looks like
Regardless of engagement model, the discovery phase is what determines whether the project is scoped correctly.
A computer vision consultancy that skips or compresses discovery is a consultancy scoping based on assumptions. When those assumptions turn out to be wrong, and in CV projects assumptions about data availability, imaging conditions, and accuracy requirements are frequently wrong, the cost gets paid during development.
What good discovery produces:
A feasibility assessment that answers specifically: can this problem be solved with CV, at the required accuracy level, given the data that can realistically be collected, in the imaging conditions that actually exist in production? It should go beyond "yes, computer vision can solve many inspection problems" and state a specific assessment of your specific problem.
A training data plan that specifies how much data is needed, what diversity of conditions it needs to cover, how it will be collected and labeled, and what the quality control process is. This plan should exist before any development begins.
An integration map identifying every external system the CV system needs to connect to, with a preliminary assessment of integration complexity. Integration problems are the most common cause of late-stage project delays in CV projects, so identifying them early is one of the highest-value outputs of discovery.
A performance threshold document that defines what accuracy level is required for the system to be useful, how that accuracy will be measured, and what test data will be used to validate it. This document should be agreed by both parties before development starts. It becomes the success criteria the engagement is measured against.
The knowledge transfer problem
Most computer vision consultancy engagements underinvest in knowledge transfer and discover this after the consultancy has left.
The symptom: a working system that nobody internally understands well enough to debug, maintain, or improve. Every production issue requires calling the consultancy. Every enhancement requires a new engagement. The system is technically functional but operationally a liability — the organization depends on an external party to operate something it paid to own.
Preventing this requires designing knowledge transfer into the engagement from the beginning, not treating it as a handoff activity at the end.
What effective knowledge transfer includes:
Internal engineers participating in architecture decisions, not just receiving architecture documentation. Participation in model evaluation sessions where the consultancy explains what the results mean and what would be done to improve specific failure modes. Codebase walkthroughs that explain why things are structured the way they are, not just what the code does. Documentation of architectural decision records: the reasoning behind choices, the alternatives considered, the tradeoffs accepted.
What it doesn't include:
A documentation dump at project close. A single handoff meeting. A README file that describes the system's structure without explaining the reasoning.
The test: at the end of the engagement, internal engineers should be able to answer these questions without consulting the consultancy. Why was this model architecture chosen? What would we do if accuracy dropped 5% next month? How do we add new defect classes to the training data? What does the monitoring dashboard indicate about current performance?
The post-delivery reality most consultancies don't discuss
Computer vision systems in production change in ways that need ongoing attention.
The model will drift as conditions change. Camera positioning shifts. Lighting conditions vary seasonally. Product specifications evolve. New defect types appear that weren't in training data. Accuracy that was acceptable at launch gradually becomes unacceptable as conditions diverge from training.
Without monitoring, this drift is invisible until someone notices the outputs are wrong. Without a retraining process, the fix requires rebuilding what was already built.
A computer vision consultancy that delivers a model without monitoring infrastructure and a retraining plan is delivering a system with a built-in expiration date. The client discovers this somewhere between 6 and 18 months after deployment, when performance has degraded enough to notice.
What to require before delivery:
Monitoring dashboards that track model performance metrics: not just infrastructure metrics like CPU and latency, but accuracy indicators such as confidence score distributions, prediction class distributions, and flagging rates for cases sent to human review. Alert thresholds configured to fire when performance metrics change significantly. A documented retraining process that specifies what triggers retraining, how new training data is collected and labeled, and how the updated model is validated and deployed.
The right computer vision consultancy engagement model is the one that produces a capability your organization can own and improve — not a deliverable your organization depends on the consultancy to maintain.
That requires thinking through engagement structure, knowledge transfer, and post-delivery support before the contract is signed, not after something breaks in production.
