Every team handed an AI mandate reaches the same fork. Do we build this ourselves, with engineers who know our business, or do we buy something and adapt? With AI the question feels sharper, because the tooling is moving fast and "we could just build it" rolls off the tongue faster than ever, then quietly becomes the thing nobody wants to maintain. This is a framework for deciding well, including a third option most build-versus-buy debates leave out.
I will be upfront that we sell a platform, so weigh the closing section accordingly. The framework itself is drawn from established sources and applies whatever you choose.
The only question that really sorts it
The most durable framing is the oldest. Geoffrey Moore split company activities into core, the things that create competitive advantage and that rivals cannot easily copy, and context, the necessary work that does not differentiate you (Moore, HBR, 2004). His prescription was to pour scarce talent into core and standardize or outsource context. Martin Fowler frames the same decision as utility versus strategic: if a process is part of your competitive advantage, build it; if it just needs to work, buy a package and adapt your process to it (Fowler).
The trap is answering at the level of the whole product instead of the component. A month-end close is context for almost everyone, even though the data inside it is sensitive. The model behind a customer-facing recommendation might be genuinely core. Thoughtworks makes this concrete: decide per component, build the differentiating parts, and buy the repeatable ones inside the same system (Thoughtworks). Ask the differentiation question of each piece, not the project.
What in-house actually costs
Building feels cheaper because the upfront estimate only counts the build. The record on large software projects is not kind. A McKinsey and Oxford study of more than 5,000 IT projects found that large efforts ran on average 45% over budget while delivering 56% less value than predicted, and that 17% went so badly they threatened the business (McKinsey, 2012). Software maintenance, not initial development, is where most lifecycle cost lives, a finding stable across decades of engineering literature.
AI adds its own running costs that a one-time build estimate ignores:
- The model moves under you. OpenAI announced the retirement of six models in early 2026; Anthropic gives as little as 60 days before retiring a released model (OpenAI). Prompts tuned for last year's model quietly regress on this year's, so migration is a recurring tax, not a one-off.
- The token bill scales with success. Uber reportedly burned its 2026 AI budget in four months, and a Goldman Sachs analysis projected agentic systems could raise token demand by up to 24 times (TechCrunch, 2026). We worked through that math in a separate piece on runtime token cost.
- The hidden operational layers. Evaluation harnesses, monitoring, security review, and the people to run them. A practitioner rule of thumb that keeps proving true is that building the AI is roughly 20% of the effort and keeping it alive in production is the other 80%.
And the outcomes show the strain. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and McKinsey's 2025 survey found 51% of organizations had at least one negative AI-related incident in the prior year (McKinsey, 2025). The same MIT study that found most pilots stalling also found that buying from specialized vendors succeeded about 67% of the time, roughly twice the rate of internal builds (MIT NANDA, 2025).
The third option most debates skip
Build-versus-buy usually gets framed as two choices: write the code yourself, or rent someone's SaaS. That framing hides a third option, a commercial platform you self-host, running on your own infrastructure. It gives you much of what pushes teams toward building, control of where data lives and freedom from a single vendor's cloud, without the cost and risk of building the platform itself.
This matters most when the reason you were tempted to build was never differentiation but control. If your hesitation about buying is that you cannot send regulated data to someone else's servers, self-hosting answers that directly, and the demand is real: Gartner expects most European and Middle Eastern enterprises to move workloads toward sovereign or self-controlled options by 2030 (Gartner, 2025). The honest trade-off is operational: self-hosting means you own patching, backups, and uptime for the deployment. For a regulated firm that already runs its own infrastructure, that is a familiar cost, not a new discipline.
| Build in-house | Buy SaaS | Self-host a platform | |
|---|---|---|---|
| Time to value | Slowest | Fastest | Fast |
| Data control | Full | Vendor's cloud | Full, on your infra |
| Maintenance burden | You own all of it | Vendor owns it | Shared: vendor builds, you operate |
| Lock-in risk | Low, but you own the code forever | Higher | Lower: your infra, exportable |
A decision checklist
Work through these per component, not per project. Honest answers usually point clearly one way.
- Differentiation. Does this capability shape how you compete, or does it just need to work reliably? Build core, buy context.
- Proprietary edge. Do you have data or workflow logic an off-the-shelf product structurally cannot replicate? That is the strongest reason to build.
- Customization tax. Will you have to heavily customize a bought product to fit your process? Past a point, you have lost the benefit of buying.
- The real reason to hesitate. If you lean toward building only because of data control or vendor dependence, a self-hosted platform may give you that without the build.
- The 80%. Can you staff not just the build but the ongoing maintenance, evals, and security work? If not, buy or self-host.
- Three-to-five-year cost. Have you counted maintenance, model migration, the token bill, and talent, not just the initial build?
- Catastrophic risk. Which failure could actually hurt the business, and which option contains it best?
Where we fit, honestly
Dittah is the self-hosted-platform option. You build your workflows with AI at design time, publishing freezes them into versioned code, and they run on your own infrastructure with no per-run token bill. That suits a specific case: the workflow itself is context, not your competitive edge, but the data is sensitive enough that pure SaaS is uncomfortable, and you would rather not spend two years building a platform to get there. If your AI capability genuinely is your differentiator, build it, and build it well. If it is regulated, repeatable work that simply has to be right, self-hosting a platform is usually the better trade. You can run the Community edition on your own servers, or see how the editions compare, and test that claim against your own work.
Bottom line
Build what differentiates you. Buy or self-host what merely needs to work. The mistake is not choosing build or buy, it is deciding at the level of the whole project, undercounting what in-house AI costs to keep running, and forgetting that self-hosting a platform sits between the two. Run the checklist per component and count the full multi-year cost, not just the build. Then ask yourself honestly whether the thing you want to build is your edge, or just work that has to be done right.
Sources are linked inline and reflect material available as of May 2026. Figures from forecasts and surveys are presented as such; cost ranges from vendor analyses are directional, not benchmarks.
