A manufacturing company needs a visual inspection system. Two paths:
Buy a commercial platform — Cognex ViDi, MVTec HALCON, Landing AI — with pre-built models, vendor support, and a six-figure annual license.
Build a custom pipeline with open-source tools — Anomalib, Roboflow, a custom inference stack — with full control, no license fees, and a team that needs to maintain everything.
The total cost difference over three years is somewhere between $500K and $2M. And most organizations make this decision in a single meeting, based on one or two data points: license cost and time-to-demo.
Both of those data points are misleading.
What the buy side doesn't tell you
Commercial platforms demo beautifully. The vendor shows your specific defect type, classified in minutes, with a drag-and-drop interface. But the demo uses curated data, controlled lighting, and a single product variant.
Day Two questions the vendor won't answer confidently: What happens when you add a new product variant? How do you handle model drift when the input distribution shifts? Can you export the model if you leave the platform? What's the latency at your actual frame rate with your actual image resolution? How does it integrate with your PLC and existing reject mechanism?
Vendor lock-in is the slow-motion risk. Once your production line depends on a specific platform's API, model format, and triggering protocol, switching costs compound annually. Year one is a license fee. Year three is a dependency.
What the build side doesn't tell you
Open-source tools are free. Building a production system with them is not.
The “minimum viable team” for a production vision AI system includes: a computer vision engineer who understands camera hardware, an ML engineer who can train and retrain models, a systems engineer who can build reliable capture and inference pipelines, and an operator who can monitor and respond to failures.
That's four roles — and in most organizations, at least two of them don't exist yet. You're not just building a system. You're building a team. And recruiting ML engineers for manufacturing inspection is one of the hardest hiring problems in the industry.
Then there's the benchmark-to-production gap. State-of-the-art anomaly detection reports 97-99% AUROC on MVTec AD. The same methods score below 60% AU-PRO on domain-shifted production data in RobustAD. Your open-source build will hit the same wall — and unlike the vendor, you don't have a support team to call.
How to actually make this decision
Start with your team, not your technology. If you don't have (and can't hire) the engineering talent to build and maintain a custom system, buy — regardless of the license cost. The most expensive AI system is the one nobody can fix when it breaks.
Evaluate switching costs, not entry costs. Ask the vendor: can you export your trained model? Can you run inference on your own hardware? What happens to your data if you cancel? If the answers are no, no, and “we'll discuss that,” factor three years of lock-in into your cost model.
Run a real validation, not a demo. Whether you build or buy, test on your actual production data, at your actual line speed, under your actual lighting conditions, for at least two weeks. AUROC on a curated dataset is not a deployment decision. Pass rate under production conditions is.
The build-versus-buy decision isn't a cost comparison. It's a bet on which set of Day Two problems you're better equipped to handle.
Navigating a build vs. buy decision?
Talk to Us