Build vs Buy Is the Wrong Question. What Is Your Actual Moat?
The False Binary
Every technology decision in a growing company eventually arrives at the same framing: should this capability be built internally or purchased from a vendor? The question has a certain executive elegance — it is binary, it implies a decision point, and it suggests that the answer will be determined by a rational analysis of cost, capability, and strategic importance.
In practice, the build-vs-buy frame obscures the question that actually determines long-term competitive position: what is the genuine source of differentiated value in this business, and what infrastructure does it require?
When that question is answered first, the build-vs-buy decision often becomes straightforward — not because the analysis is simple, but because the frame is right. Build what constitutes the moat. Buy everything else. The cost is legitimate. The moat is what the organisation is actually paying for.
The organisations that get into trouble — the ones that spend three years and significant capital building infrastructure that is available more cheaply from vendors, or the ones that outsource the capabilities that were actually differentiating — typically got into trouble at the framing stage, not the analysis stage.
This pattern has become significantly more acute with AI. The availability of powerful AI capabilities through commercial APIs has expanded the universe of what can be purchased, but it has also created a new category of confusion: organisations that are purchasing AI capabilities that are available to every competitor, believing this constitutes a competitive advantage, while failing to invest in the proprietary data and workflows that would make those capabilities genuinely differentiating. A 2025 Bain & Company survey found that 71 percent of executives believed their AI investments were building competitive advantage, while independent analysis of those investments found that 54 percent were deploying capabilities available to all competitors on equivalent terms. The gap between belief and reality is the build-vs-buy problem expressed in AI terms.
Three Failure Modes of Getting the Frame Wrong
Failure Mode One: Building What Should Be Bought
The most common failure is building generic infrastructure in-house rather than purchasing it, on the grounds that the capability is important enough to require internal control.
Internal control is a legitimate concern. It becomes a cost centre rather than a value driver when applied to capabilities that are not differentiating — capabilities that are required for the business to function but that do not produce better outcomes when built internally than when purchased.
Authentication is an example: every software product requires authentication, and some organisations spend significant engineering resources building proprietary authentication systems. The authentication system is not their moat. It is the infrastructure that everything else depends on. The decision to build it internally rather than use one of several mature commercial alternatives is a decision to spend engineering capacity on a generic problem at the cost of engineering capacity that could have been applied to the differentiating capability.
The same logic applies to most of the infrastructure layer of software products: hosting, deployment pipelines, standard API integrations, data storage, observability. These capabilities are required; they are not differentiating. Building them internally is a choice to apply constrained resources to undifferentiated work. The cost compounds over time because the internal build requires ongoing maintenance, creates single points of dependency on the engineers who built it, and grows increasingly divergent from best practices as the external vendors invest in the capability more heavily than any individual organisation can justify.
In the AI context, this failure mode appears as organisations building their own retrieval infrastructure, their own vector databases, their own model serving layers — all capabilities for which mature commercial solutions exist — while the genuinely proprietary work of training on their own data, building their own domain-specific evaluation frameworks, and integrating AI into their specific operational workflows goes unresourced.
Failure Mode Two: Outsourcing What Should Be Owned
The inverse failure is more expensive because it is less visible: outsourcing the capability that is actually differentiating.
The moat is often not what an organisation thinks it is. A fintech company may believe its moat is its user interface, while the actual source of differentiated value is the data pipeline that produces superior credit risk predictions. A fund manager may believe its moat is its investment team, while the genuinely proprietary capability is the operational infrastructure that allows the team to execute more efficiently than competitors. A legal services company may believe its moat is its partner network, while the differentiator is the document processing capability that allows it to handle volume at a margin that competitors cannot match.
When the genuine moat is outsourced — when the capability that actually produces the differentiated outcome is provided by a vendor whose service is also available to every competitor — the competitive advantage is defined by a vendor relationship rather than by internal capability. This is a fragile position: the competitive advantage changes when the vendor's pricing changes, when the vendor's terms of service change, or when the vendor is acquired by a competitor.
The diagnostic for this failure mode is asking why current clients or partners choose the organisation over alternatives, and then tracing that reason back to the specific operational capabilities that produce it. The answer is often not what the organisation's narrative about itself would suggest. The investment management firm that believes clients choose it for its investment philosophy may discover, on careful examination, that the clients most resistant to attrition are those using its portfolio monitoring reporting — a service built on a proprietary data integration that a competitor could not quickly replicate. The reporting is the moat. The investment philosophy is the narrative.
Failure Mode Three: Confusing the Moat with the Scaffolding
The third failure mode is attempting to build everything internally without the discipline to distinguish between what constitutes the moat and what constitutes the scaffolding that the moat depends on.
This failure is characteristic of organisations with strong internal engineering cultures and access to capital — organisations where the default answer to "should we build this?" is yes, because the capability exists and the resource is available. The result is an engineering organisation that is building more things than it is maintaining or improving, a technology estate that is broad and shallow rather than narrow and deep, and a moat that is harder to identify with each passing quarter because internal capability has been spread across an increasing number of undifferentiated domains.
The discipline of building only the moat requires accepting that the scaffolding is legitimately not the moat — that relying on vendors for generic capabilities is not a strategic weakness but a correct allocation of constrained engineering resources. This acceptance runs against the instincts of most engineering-led organisations, which regard internal control of infrastructure as inherently superior to vendor dependency.
The counterargument is not complicated: the vendor of a generic capability that serves many organisations has invested more in that capability than any individual organisation can justify. The cloud provider's storage infrastructure, the observability vendor's monitoring platform, the commercial AI model provider's inference infrastructure — all of these represent investments that dwarf what any individual organisation would commit to equivalent internal development. Using them is not accepting dependence on a vendor. It is accepting the leverage that specialisation provides.
The University Research Team Case
The clearest illustration of the correct approach is not from a large enterprise but from a small team with constrained resources and a specific, defensible problem.
A university research group identified that companies expanding across borders were spending significantly on local legal consultants, compliance reviews, and penalty exposure from regulatory errors. The research team had observed that legislation patterns existed across jurisdictions — that the underlying logic of employment law, corporate governance requirements, and cross-border transaction rules shared structural similarities that a sufficiently capable analysis tool could identify and map.
The team began with £200,000 in grant funding. The decision about what to build and what to buy was made explicitly and held throughout the growth of the organisation.
They outsourced UI/UX design and initial product engineering. These capabilities were required for the product to function; they were not the source of differentiated value. The product could have a mediocre interface and still be used by clients who needed the core capability. Investing in premium interface design before the core capability was validated would have been a misallocation of constrained resource.
They built, internally, the LLM pipeline that scraped, translated, and normalised legislation across jurisdictions. This was the moat: the proprietary capability to take Japanese corporate law, translate it semantically rather than literally, and map its requirements against German equivalents in a way that could answer specific cross-border compliance questions. No vendor provided this capability. It could not be purchased. It had to be built, and building it well was the entire value proposition of the organisation.
They used off-the-shelf tools for everything else. Spreadsheets. Standard databases. Commercial hosting. Existing authentication solutions. The team was five people. Using off-the-shelf tools for generic infrastructure was not a concession to resource constraints — it was the deliberate preservation of those five people's capacity for the work that constituted the moat.
Through Series A, with fifteen people, the same philosophy held: the core team remained focused on the legislative AI engine; vendors handled supplemental functions and proofs of concept; three or four reliable technology providers delivered the database, hosting, and authentication infrastructure.
Only at Series B, with eighty core employees and multiple product lines, did the team begin consolidating infrastructure into a proprietary vertical workflow platform. Not because they could afford it earlier — they could have raised more capital and built it earlier. Because they had accumulated sufficient clarity about what constituted the moat and what constituted the scaffolding to invest in building the scaffolding correctly, having proven that the moat was real and valuable. The sequence — prove the moat, then invest in the scaffolding — is the correct one. Most organisations reverse it.
The Diagnostic Questions
The build-vs-buy decision becomes tractable once the moat is identified. The questions that help identify it:
Why do current clients choose the organisation over alternatives? The honest answer — not the marketing version, but the operational reason — points toward the differentiating capability.
What would be lost if the capability were purchased from a vendor and the vendor also served every competitor? If the answer is "not much," the capability is infrastructure, not moat.
Where does the organisation's performance exceed the market average, and what produces that excess performance? The excess is the moat; the operational capabilities producing it are what should be built internally.
What capabilities require proprietary data, proprietary processes, or proprietary domain knowledge to build effectively? These cannot be adequately provided by a vendor serving a general market. They must be built internally if they are to be built at all.
In the AI context, a fifth diagnostic question has become essential: what data does the organisation possess that competitors cannot access, and what would an AI system built on that data enable? This question often surfaces the moat more clearly than any of the others, because proprietary data is increasingly the primary source of durable AI advantage. The organisation that can answer this question specifically has identified its moat. The organisation that cannot has either not yet found it or is in a commodity market where sustainable differentiation through AI is unlikely.
How AI Specifically Changes the Moat Question
AI has not changed the fundamental logic of the build-vs-buy framework, but it has introduced a new class of moat opportunity and a new class of moat threat that the traditional framework did not need to address.
The new moat opportunity is proprietary AI capability built on proprietary data. The organisations that possess data that competitors cannot access — years of transaction records, client interaction histories, operational decisions made across thousands of engagements — now have the raw material to build AI systems that are genuinely not replicable through purchasing the same commercial model and deploying it against general data. A language model fine-tuned on an organisation's proprietary interaction data, calibrated to the specific decision patterns of a specific business, produces outputs that a competitor cannot replicate by purchasing the same base model. The moat is not the model. It is the calibration, and the data that makes the calibration possible.
This is a significant change from the pre-AI environment. In conventional software, intellectual property and brand were the primary non-replicable competitive assets. In the AI environment, proprietary data has been added as a third category of non-replicable asset — and for most enterprises, it is the one most directly accessible, because it already exists in their operational systems, waiting to be used.
The new moat threat is AI-assisted commoditisation of capabilities that were previously differentiating. When a senior professional with an AI coding assistant can produce the same output as a team of junior professionals — and do so faster and at higher quality — the labour cost that made a service differentiating on margin rather than on capability is eroded. When AI can produce the research summary that previously required a proprietary research process, the research process ceases to be a moat. The diagnostic question — what would be lost if this capability were purchased from a vendor and the vendor also served every competitor — now has a larger category of concerning answers, because AI is making more capabilities purchasable on equivalent terms.
The implication is that the moat identification exercise needs to be revisited more frequently than in the pre-AI era. Capabilities that were genuinely differentiating in 2022 may have been commoditised by AI in 2025. The organisation that identified its moat three years ago and has been investing in maintaining it needs to re-examine whether the capability is still non-replicable by competitors with access to current AI tools. If it is not, the investment has been maintaining infrastructure, not a moat — and the actual moat needs to be found and invested in.
The Allocation That Follows
Once the moat is identified, the allocation decision follows. Build what constitutes the moat. Purchase everything else from providers who have invested more in those generic capabilities than any individual organisation could justify. Apply the engineering resources that would have gone to the scaffolding to deepening and extending the moat instead.
This is not a particularly complicated framework. The difficulty is in applying it honestly — accepting that the capabilities that feel important because they are visible, because they required significant past investment, or because they are points of organisational pride, may not actually be differentiating. The moat is what produces outcomes that competitors cannot replicate. Everything else is scaffolding, and scaffolding should be purchased from the people who build scaffolding for a living.
The organisations that have understood this have built lean, focused, and durable competitive positions. They are also, not coincidentally, the organisations extracting the most value from AI — because they have directed AI investment toward their actual sources of differentiation, building proprietary capabilities on proprietary data, rather than purchasing the same AI tools that every competitor also has access to.
The ones still asking the wrong question are building a lot of expensive scaffolding and calling it strategy. The scaffolding will be commoditised. The moat, if it was real and was built properly, will not.
