The Binary That Is Not Actually Binary
CTOs are routinely presented with the AI capability question as a binary: buy SaaS-delivered AI from a vendor, or build internal AI capability. Vendors prefer the former framing. Engineering leadership often prefers the latter. Both framings produce wrong answers in roughly half the cases.
The real question is portfolio composition. Most enterprises will end up with multiple AI capabilities, some bought as services, some built in-house, and some structured as hybrid arrangements where vendor infrastructure carries the heavy lifting and internal engineering builds the differentiated layer above. Forrester's 2024 enterprise AI research suggests roughly 65 percent of mature AI portfolios in 2026 will use this hybrid structure rather than pure buy or pure build (Forrester, "The State of Enterprise AI, 2024").
If your AI strategy is presented as a single buy-versus-build choice, you are about to make a portfolio decision with insufficient granularity.
The Five Workload Categories
AI workloads in an enterprise sort into five categories, each with different buy-build economics.
The first category is generic productivity AI. Code assistants, document drafting, transcription, generic summarization. The capability is widely available, the SaaS market is mature, and internal differentiation is impossible. Buy.
The second category is industry-specific decision support. Clinical decision support, claims analysis, credit risk scoring. Vertical SaaS exists. The question is whether the vertical SaaS fits your specific operational reality or whether internal customization adds enough value to justify it. Often hybrid: vertical SaaS as foundation with internal customization on top.
The third category is core differentiated capability. The AI that customers experience as part of what makes your product specifically yours. Recommendation engines for retail, personalization for media, automated underwriting for specific insurance lines. Build, almost always, because the value is in the specifics that vendors cannot capture.
The fourth category is infrastructure and tooling. Vector databases, model gateways, evaluation harnesses, observability. Buy in 2026. The market is mature. Internal builds in this category have largely lost the buy-versus-build argument over the past two years.
The fifth category is bridge work. The integration glue between bought tools and internal systems, the customization layer that adapts vendor capability to your specific data and processes. Build, narrowly, because no one else can build this for you.
The portfolio decision is a category assignment exercise. Each AI capability in your portfolio fits in one of these five. Each category has a default answer. The exceptions to the defaults are usually obvious once the assignment is made.
What Drives Category Assignment Wrong
Three common patterns produce wrong category assignments.
Sales pressure pushes generic productivity AI into the "core differentiated" category. Vendors of generic AI tools claim differentiation that does not exist at the application layer. CTOs sometimes agree because internal politics favor the "we are building proprietary AI" framing. The capability is generic regardless of how it is framed.
Engineering pride pushes infrastructure and tooling into the "build" category. Senior engineers see internal builds as more interesting than vendor integration. Some of the most expensive enterprise mistakes in 2023 and 2024 were internal builds of categories where the buy market had matured. Most of these have quietly converged to buy in 2025-2026.
Strategic ambiguity pushes core differentiated capability into the "buy" category. The capability that should be your moat gets outsourced to a vendor who delivers the same capability to your competitors. The cost savings are real and the strategic cost is larger.
The teams that get category assignment right are usually deliberate about it. The teams that get it wrong are usually defaulting to whichever option is currently in fashion.
The Honest Cost Comparison
Most buy-versus-build comparisons compare list pricing of the SaaS option against optimistic estimates of the build option. Both numbers are wrong.
The realistic buy cost includes license fees, implementation services, integration engineering, vendor management, contract negotiation, and the ongoing cost of operating around the vendor's quirks. For enterprise SaaS, the true cost is typically 1.5x to 2.5x the headline license price.
The realistic build cost includes initial engineering, ongoing maintenance, security patches, integration with adjacent systems, opportunity cost of engineering time, and the cost of failure paths that vendors have already debugged. The true cost is typically 2x to 4x the initial build estimate, with the multiplier growing if the workload is more specialized than the team assumed.
When both numbers are calculated honestly, the decision is usually clearer than either party expects. The hybrid pattern often wins because it isolates the build investment in the layer where it pays back and uses bought capability for the layer where it does not.
What This Looks Like in a Real Portfolio
A mid-market enterprise CTO's AI portfolio in 2026 typically contains 8 to 15 AI capabilities. The well-managed portfolio distributes across the five categories roughly as follows.
Three to five generic productivity capabilities bought as services. Code assistant, transcription, document drafting, possibly meeting summarization. License costs concentrate here.
One or two industry-specific decision support capabilities. Often hybrid where vertical SaaS provides the base and internal team builds customization.
Two to four core differentiated capabilities built internally. These are the AI features that customers specifically experience as your product. Engineering investment concentrates here.
Three to six infrastructure and tooling components bought as services. Vector databases, evaluation, observability, model gateways. Each is a buy decision; combined, they form the platform layer.
Bridge work spans the portfolio rather than appearing as discrete items. Two to four senior engineers per quarter typically spend their time on this category, which is invisible in capability inventories but visible in the platform's actual coherence.
This portfolio composition recurs across well-managed enterprises. Deviations from it usually trace to specific drivers (regulatory, scale, strategy) rather than to general principle.
What Logiciel Does Here
Logiciel works with CTOs structuring AI portfolios where the buy-versus-build decisions have been made one at a time without a coherent framework. The work is typically a portfolio review against the five-category model followed by a sequence of category-correct decisions for the capabilities that are currently misassigned.
The Build vs Buy AI Tooling framework covers the five-quadrant model used for individual decisions. The AI Dev Services Real vs Hype framework covers the four-category workload model used for engineering services specifically.
A 30-minute working session is enough to map your current AI portfolio against the five categories.
Frequently Asked Questions
How do I tell if my AI capability is genuinely differentiated?
Ask: would a customer pay differently for the same product feature implemented by a vendor versus implemented by your team. If the answer is yes, the capability is differentiated. If the answer is no, it is generic regardless of how the team feels about it.
How do I handle vendor lock-in concerns?
Through architecture, not through avoiding buy. Abstraction layers between your code and vendor APIs, explicit exit planning for critical vendors, multi-vendor designs where the workload genuinely supports it. Lock-in is bounded through design, not avoided through internal builds.
What happens if my needs change after the buy decision?
Most vendor relationships allow workload expansion within the existing contract. Workload contraction is harder but usually possible at contract renewal. The decisions that prove durable are usually the ones where the underlying workload category is stable rather than the specific feature mix.
When should I switch from buy to build?
When the buy option no longer fits the use case, when the cost differential structurally favors build (rare), or when the capability has moved into the core differentiated category. Switching for small cost differences rarely pays back the switching cost.
How does the EU AI Act affect this decision?
It shifts the cost balance toward vendors that have invested in compliance documentation. Building AI capability that has to clear EU AI Act high-risk requirements is meaningfully more expensive than buying from vendors that have already done the work. Sources: - Forrester, "The State of Enterprise AI, 2024" - European Commission, AI Act timeline
