Every enterprise AI initiative eventually arrives at the same fork, and the signage hasn't been updated in years. You can either build, which entails hiring or hiring engineers, running a discovery phase, and constructing something tailored over two or three quarters. Or you can buy, which requires purchasing a license for an off-the-shelf product and accept whatever fit it offers.
Teams searching for custom AI solutions have usually already tried the buy aisle and found everything on the shelf collecting dust. So they wander toward build, where the proposals start with a comma and the timelines start next fiscal year.
Here's the Unframe position, argued straight. The build vs. buy question is the right question with an obsolete answer set. Both classic answers concede something enterprises no longer have to concede. Build concedes speed, cost, and sustainability. Buy concedes fit.
The third answer, true custom AI solutions configured on a managed platform, refuses the trade. With that in mind, the rest of this piece makes the case for why it’s the solution for most of the enterprise backlog.
What does building custom AI get right, and what does it cost?
We've walked through the hidden cost of AI in production when you build. And truth be told, the arc repeats across industries. Ultimately, maintenance consumes the business case that development wrote. The myth of reusable AI in the enterprise compounds it, because build number two reuses far less of build number one than the proposal promised. So the portfolio never gets cheaper, just bigger.
McKinsey's State of AI survey found nearly 9 in 10 organizations using AI regularly, with only about 6% qualify as high performers capturing material bottom-line impact. That gap lives in production, in exactly the maintenance-and-integration territory where custom builds go to stall.
When does buying off-the-shelf AI work, and where does it fall short?
The buy instinct is rational. For commodity workflows it's the correct answer, full stop. The benefits end where your specifics begin. Off-the-shelf extraction stumbles on your document formats, off-the-shelf workflows fight your approval chains, and the data-handling terms in the standard contract were written for someone with less to lose than you.
Teams will then stack workarounds on top of the product until the workarounds are the product. Which is how a buy decision quietly becomes an unplanned build.
The fuller comparison lives in our piece on off-the-shelf AI vs. managed AI, and its conclusion frames the fork honestly. Both classic paths make you choose between fit and speed.
What is the configured alternative to build vs. buy?
The configured model is the third answer. Custom where it matters, shared where it doesn't. Decompose any enterprise AI use case and it splits into two layers. The hard engineering, extraction, retrieval, orchestration, guardrails, and monitoring, is the same across companies. And rebuilding it per enterprise is the industry's most expensive habit.
The fit layer, which is your data connections, rules, workflows, vocabulary, and security boundary, is yours alone. And it's where the value hides. The configured model assigns each layer to the right owner.
AI building blocks carry the engineering, maintained and upgraded continuously for everyone, while configuration on a modular platform carries the fit, on your specifics, in your environment. Custom AI solutions delivered this way behave differently on every axis the fork cares about:
- Speed: Production in days and weeks rather than quarters, because the engineering already exists.
- Fit: Real, structural fit, including the one bespoke builds struggle hardest to guarantee, AI that runs without your data ever leaving your boundary.
- Sustainability: The platform absorbs model churn because the architecture stays LLM-agnostic, so better models arrive as upgrades rather than rewrites.
- Portfolio economics that compound: Use case two inherits the connections, controls, and learnings of use case one. Which is the reuse builds promise but platforms deliver.
When should you still build custom AI in-house?
You should build in-house when AI is the product. When your differentiation lives in the model work. Build when the use case sits at the true research frontier, where no platform has componentized the problem yet. Build when you have a standing ML engineering organization with capacity, mandate, and the appetite to own production forever. That list is real, but short.
The document processing, compliance workflows, knowledge access, extraction, and agent operations filling actual enterprise backlogs are fit problems. And fit problems reward assembly with judgment over invention with invoices.
The test for any given use case takes one question. Does this need something that has never existed, or does it need existing capability shaped precisely to us? Be suspicious of any vendor answering "never existed" about a workflow a hundred other enterprises also run.
Novelty is the most overdiagnosed condition in enterprise AI, and the misdiagnosis is rarely innocent. Effort-billed engagements need the problem to be special, because special justifies the discovery phase, the dedicated team, and the change orders.
The configured model has the opposite incentive since a platform provider profits from the problem being solved. Follow the incentives when you read the proposals, and weigh the opinion of whoever has to live with the system in year three.
How do you decide between build, buy, and configure?
When a use case lands on your desk, score it against five questions and let the columns argue:
- Does the need need invention or fit?
Invention points to build, fit points away from it - How fast do you need it?
Quarters tolerate build, weeks demand configuration - Who maintains it in year two?
An ML org supports build - How sensitive is the data?
High sensitivity disqualifies most off-the-shelf terms - How many similar use cases follow this one?
A portfolio amortizes a platform while a one-off might justify either extreme
With honest answers, the pattern repeats across enterprises. The value of scoring it explicitly is political as much as analytical. A one-page matrix ends the annual re-litigating of custom AI solutions that consumes steering committees because the framework decides.
Who carries the risk in a custom AI engagement?
One structural difference outranks the rest for anyone who owns a budget. A development engagement bills for effort. Variables like hours, milestones, and deliverables, independent of whether the result ever moves your numbers. You carry the outcome risk entirely, at solution prices.
A managed platform can invert that, pricing on outcomes rather than effort. And if that wasn’t compelling enough, they even remove upfront costs from the adoption decision because a provider who controls the platform can stand behind results.
The delivery arc under the configured model also deserves a nod because it's where the difference becomes visible to executives. Weeks one and two connect data and systems, configure the first workflow, and run production documents through it. Weeks three and four tune against your acceptance metrics with your reviewers in the loop.
From there, it’s all about expansion. The next workflow inherits everything, which is when the portfolio math flips and custom AI solutions stop being projects and become capabilities. If you’re ready to start buying results instead of risk, we should connect.
Enterprise AI: Build or Buy?
FAQs
What counts as custom AI solutions if nothing gets coded from scratch?
Custom means the solution fits your data, systems, workflows, vocabulary, and security constraints. A platform configured to all five is custom where it matters; the code underneath being shared, maintained components is precisely why it ships in weeks and keeps improving.
Is build vs. buy still the right frame for enterprise AI?
It's the right question with an outdated answer set. Building from scratch and buying off-the-shelf both concede something critical; the configured platform model is the third option that takes fit from build and speed from buy without the maintenance tail or the shelf-shaped compromises.
What does bespoke AI development really cost over three years?
The launch budget is the visible fraction. Add model updates the hardcoded stack can't absorb, integration repairs when source systems change, compliance rework, and the specialist team that maintains it all. Industry research consistently finds the gap between AI adoption and bottom-line impact lives in exactly this production phase.
When should an enterprise still build custom AI in-house?
When AI is the product itself, when the use case sits at the true research frontier, or when a standing ML organization has both capacity and mandate. For fit problems, which describe most enterprise backlogs, configuration beats construction on speed, cost, and sustainability.
How does outcome-based pricing change the custom AI decision?
Development engagements bill for effort whether or not the result works; you carry the outcome risk. A managed platform can price on delivered results because it controls enough of the stack to stand behind them, which aligns incentives no statement of work replicates.
.svg)