What 'build' and 'buy' mean for an AI workflow
In this context, buying means adopting a packaged platform that already handles orchestration, retrieval, and the model call as one product, usually configured through settings rather than code. Building means writing and owning the code that wires the model API, your business rules, and your data access together.
Few real decisions are purely one or the other. A common middle path is buying the model API and the infrastructure underneath it, while building the orchestration and decision logic that make the workflow specific to the business.
Ask where the differentiation actually lives
If the value of the workflow comes from business-specific rules, a particular combination of internal data sources, or a decision boundary that is unique to how the company operates, that logic is worth owning directly. A vendor platform will either not support it or will force the business to bend its process to fit the product.
If the workflow is close to a well-understood, common pattern across many businesses, a platform built for that exact pattern often reaches production faster and with fewer defects than a custom build, because the vendor has already handled the edge cases.
- Lean build: the workflow touches proprietary data combinations or rules that define a competitive edge.
- Lean buy: the workflow is a common pattern (ticket triage, meeting summarization, lead qualification) with many existing solutions.
- Lean build: the team already owns the surrounding system the workflow plugs into.
- Lean buy: speed to a working version matters more right now than long-term customization.
Price in the cost of leaving, not just the cost of entering
Switching costs are the core risk of buying, and they are usually invisible at signup. A platform that stores prompts, rules, and workflow history in a proprietary format can make the business dependent on it well beyond the original use case, even if a cheaper or better option appears later.
Before signing, get a direct answer to three questions: can the underlying data be exported in a usable format, can the business logic (prompts, rules, decision thresholds) be read and copied out, and does the pricing model stay predictable as usage grows. A vendor that cannot answer these clearly is asking the business to accept lock-in risk without naming it.
Decide per workflow, and revisit on a schedule
The build-or-buy decision does not need to be made once for the whole company. A business can buy a platform for a commodity workflow like inbox triage while building its own orchestration for a workflow tied to a regulated or proprietary process, and both choices can be correct at the same time.
Whichever path is chosen, set a concrete point to revisit it, tied to a contract renewal date or a volume threshold, rather than leaving it as an open-ended 'we'll reconsider later.' Vendor pricing and internal engineering capacity both change, and the right call six months in is not guaranteed to match the right call on day one.