Build vs. buy for AI: a framework for mid-market decision-making

The build-vs-buy decision for AI is different from traditional software procurement. The technology shifts every six months. A vendor that is state-of-the-art in January may be commoditized by July. A custom model trained on proprietary data may outperform any SaaS product -- but only if you have the engineering bench to maintain it.

Mid-market companies feel this tension more than most. They are large enough to have unique workflows worth automating, but rarely large enough to staff a dedicated ML engineering team. The right answer depends less on what is technically possible and more on where the company's differentiation actually lives.

Ask one question: does this workflow generate outsized value because of how we do it, or is it a cost center we need to manage efficiently? If the former, build. If the latter, buy.

Consider a specialty insurance firm that underwrites niche risk categories. Their underwriting logic is their moat -- a custom AI model trained on their proprietary loss data will outperform any generic tool. But their HR onboarding process? That is a commodity workflow. Buy the best SaaS tool and move on.

The error most companies make is treating everything as either a build or a buy decision. The portfolio approach -- building on moat-critical workflows, buying for everything else -- consistently delivers better outcomes than either extreme.

Lock-in risk is not uniform across the AI stack. At the API layer (LLM calls, vision models, speech-to-text), switching costs are relatively low. The interfaces are converging, and most applications can swap providers with modest refactoring.

The risk concentrates in data pipelines. Once your operational data flows through a vendor's ingestion and transformation layer, migration gets expensive. Embeddings stored in a proprietary vector database, fine-tuned models hosted on a single cloud, ETL pipelines built on vendor-specific connectors -- these create dependencies that accumulate over time.

Our guidance: own your data layer, rent your model layer. Keep embeddings portable, maintain export capabilities for all training data, and insist on API-based integrations rather than platform-native ones wherever you can.

Every custom AI build costs more than the initial estimate. This is not a planning failure -- it is what happens when you build systems that interact with real-world data. Data quality issues surface after deployment. Edge cases multiply. Users request changes that seem minor but require architectural rework.

A realistic cost model for custom AI includes: initial development (the number everyone quotes), data preparation and cleaning (typically 30-40% of the build cost), ongoing model maintenance and retraining (15-25% of initial cost annually), and integration upkeep as upstream systems evolve.

Companies that account for these costs upfront make better build-vs-buy decisions than those that compare the build estimate against the annual SaaS subscription.

For most mid-market companies, the answer is neither pure build nor pure buy. It is a layered approach: buy the foundational infrastructure (cloud hosting, base models, general-purpose APIs), and build the differentiation layer on top.

In practice, this means using off-the-shelf LLMs but wrapping them in custom prompting pipelines tuned to your domain. Buying a CRM but building custom lead-scoring models that reflect your specific market signals. Using open-source frameworks but training on proprietary data.

The hybrid approach requires more architectural discipline than either extreme, but it balances speed-to-market against long-term defensibility. For companies with 50-500 employees, it is usually the right call.