The Question You Are Actually Asking
Most teams that come to me with a build-versus-buy question have already answered it wrong once. They bought a platform, customized it into something unrecognizable, and are now paying for maintenance on a system nobody fully understands. Or they built something bespoke, it worked beautifully for six months, and then the underlying model changed and the whole thing drifted.
The real question is not which option is cheapest or fastest to launch. The real question is where does the operational risk actually live in this workflow, and which approach keeps that risk manageable over time.
Get that question right and the rest of the decision becomes straightforward. Get it wrong and you will spend the next two years paying for the mistake.
Three Options and What They Actually Mean
When I say build, I mean you own the architecture, the prompts, the retrieval logic, the guardrails, and the integration layer. Your team wrote it, your team runs it, your team fixes it at 2am.
When I say buy, I mean a vendor platform handles most of that surface area. You configure it, you feed it data, you set policies. The vendor owns the core engine and the update cycle.
When I say wrap, I mean you are writing a thin orchestration layer around a foundation model or a set of APIs. You own the business logic and the integration, but you are not building retrieval from scratch or training anything. This is the middle path and it is underused.
All three are legitimate. None of them is universally right. The failure mode I see most often is teams treating this as a technology preference rather than an operational risk decision.
Where Each Option Wins in Practice
In a distribution operation I worked with, the core workflow was exception handling on inbound freight. Documents were inconsistent, carriers used different formats, and the team was spending real hours every day on manual triage. We wrapped a foundation model with a classification layer and a set of business rules the operations team already had in their heads. Total build time was six weeks. The workflow ran for eighteen months before it needed meaningful attention. That was the right call because the process was well-understood, the edge cases were manageable, and the team did not need a platform with twenty features they would never use.
In a manufacturing context, a client needed AI assistance across quality inspection, supplier communication, and production scheduling. The workflows were interconnected, the data lived in multiple systems, and the operations team had neither the time nor the appetite to manage a custom codebase. A platform made sense there because the vendor's integration library covered most of the connectivity problem and the operations team could configure workflows without engineering support.
In financial services, I have seen the opposite mistake repeatedly. Teams buy a platform for a compliance review workflow, then spend a year trying to get the platform to behave like their actual process. Compliance workflows in finance are often so specific to a firm's own policies and risk appetite that a bespoke build, expensive as it is upfront, ends up cheaper over three years because you are not fighting the platform's assumptions at every step.
The Five Questions That Drive the Decision
I use five questions with every client before we touch a single line of code or open a single vendor conversation.
- How differentiated is this process? If competitors run the same workflow roughly the same way, a platform probably covers it. If your process is a genuine source of competitive advantage or regulatory specificity, build or wrap.
- How stable is the process? A workflow that changes every quarter will break a bespoke build constantly. Platforms handle change better when the vendor is absorbing the maintenance. Wraps sit in the middle.
- Who owns it in eighteen months? If the answer is a vendor, make sure you are comfortable with that dependency. If the answer is your own team, make sure that team actually exists and has capacity.
- What does failure look like? A wrong answer in a freight triage workflow costs you a delayed shipment. A wrong answer in a loan approval workflow costs you a regulatory finding. The higher the cost of failure, the more you need to own the guardrails directly.
- What data does this touch? If the workflow requires sensitive data that cannot leave your environment, your platform options narrow immediately. This is not a technology preference, it is a constraint that eliminates choices before you start.
The Wrap Option Gets Underused and Here Is Why
Most of the teams I talk to think in binary terms. They either want to buy something turnkey or they want to own everything. The wrap approach sits in between and it is genuinely underused, usually because it requires a specific kind of engineering judgment that is hard to find.
A wrap means you are writing orchestration, not infrastructure. You are making decisions about prompt structure, retrieval strategy, output validation, and failure handling. You are not building a model or a vector database from scratch. You are assembling components with intention.
In field operations, I have used this approach for technician dispatch support, where the model needs to reason about job history, parts availability, and technician skill sets simultaneously. No platform on the market handles that specific combination well out of the box. Building it from scratch would have taken four times as long. Wrapping a foundation model with a retrieval layer and a structured output schema got us to production in ten weeks with a team of three engineers.
The honest limitation of the wrap approach is that you are dependent on the foundation model provider's reliability and pricing decisions. That is a real risk. You manage it by keeping your business logic in your own code, not embedded in prompts you cannot easily migrate.
What Goes Wrong and How to See It Coming
The most common failure I see is buying a platform for a workflow that is actually too specific for any platform to handle gracefully. The team spends the first three months configuring, the next three months working around limitations, and by month nine they are maintaining a pile of custom code inside a platform that was supposed to reduce custom code. They have the worst of both worlds.
The second most common failure is building bespoke when the process is generic. A team spends six months building invoice processing automation from scratch when three platforms would have handled it adequately. That is six months of engineering time that could have gone toward something that actually differentiates the business.
The third failure is subtler. Teams wrap a model, it works well, and then they stop paying attention to it. Foundation models update. Behavior drifts. Outputs that were reliable in month one are subtly different in month twelve. I am not saying models are perfect or that any model is free of error. I am saying that a wrap requires ongoing evaluation, not a one-time deployment. Build that into your operating model before you launch, not after something breaks.
In every case the failure was visible in advance. The team just did not ask the five questions before they started.
The Practical Takeaway
Before your next AI workflow decision, map the process on two axes. First, how differentiated is it from what your competitors do. Second, how stable is it over a two-year horizon. Highly differentiated and stable points toward bespoke build. Generic and changing points toward platform. Differentiated but changing, or generic but stable, is usually where the wrap approach earns its place.
Then run the five questions. Write down the answers. If you cannot answer who owns this in eighteen months, you are not ready to choose yet.
The teams that get this right are not the ones with the biggest budgets or the most sophisticated engineers. They are the ones that treat the decision as an operational risk question first and a technology question second. That reframe alone will save you more time and money than any specific tool or vendor ever will.