Build vs. buy is back in the headlines: How to make the right call

TL;DR: Build vs. buy keeps coming up in my conversations with data leaders this year, amid the SaaS apocalypse headlines. My take: buy by default, and build only where a capability defines your edge. Nine analyst sources agree: buying speeds time to value and frees talent, while disciplined building protects true differentiators. Blending both is the real winning move.

Build vs. buy keeps coming up in nearly every customer conversation I have this year.

Some of that renewed attention traces back to this year’s so-called SaaS apocalypse, the wave of AI coding advances that briefly rattled enterprise software stocks and left plenty of technology leaders wondering whether their teams could just build it themselves.¹ Survey data backs up the mood: one 2026 report found that more than a third of enterprises had already replaced a SaaS tool with a custom build.² I hear a version of that same impulse in my own customer meetings. One data leader told me their engineering team had floated a weekend hackathon to spin up their own catalog, half convinced AI had made buying obsolete. They walked it back within a month, once they mapped out what the catalog actually needed to do. The underlying question, though, is not new: should we build it, or should we buy it?

Reviewing nine independent sources including Harvard Business Review, Gartner, KPMG, PwC, and others, a consistent conclusion emerges: most organizations lean toward a buy‑first, building only where the capabilities are tied directly to how they differentiate or how they plan to compete long term. That is what I hear echoed in nearly every one of these conversations.

This conclusion is grounded in evidence, industry experience, and analysts’ recommendations. KPMG finds that only 12% of organizations build their AI in-house, and half lack the talent to do it.³ Gartner puts a number on the shift too: 76% of enterprise application spend now goes to commercial and low-code software.⁴

Taken together, these sources point to a simple principle: Blend everything. Buy what gets you moving quickly and what many organizations need. Build what defines your company or makes you different, and what only you need.

Why is buying the default approach?

Data governance is an example of where the buy case gets tested, and it is where organizations often underestimate what they are up against. It is tempting to mistake a quick AI-developed prototype for a production-grade capability. KPMG highlights that building internally requires a company culture ready for trial and error, since success is rarely immediate. Getting governance right from the start matters more than ever. Data leaders often describe a catalog as if it’s just a list of assets. It isn’t. A proper catalog needs an assortment of core features like automated metadata harvesting, connectors into dozens of systems, schema change detection, version history, tagging workflows, search relevance, an open meta-model and role based access. Vendors have spent years refining these capabilities. Re-creating them internally is not a quick build, it’s a multi-year engineering program.

“Buying is not  a shortcut. It is a strategic allocation of time, talent, and attention.”

Lineage is another area where organizations building their own data capabilities get caught out. Gartner has repeatedly highlighted lineage as one of the hardest data engineering challenges. True lineage means parsing SQL and pipelines across multiple engines, tracking transformations, versioning, impact analysis, and producing visualizations that auditors and regulators can rely on. These visuals aren’t just basic mappings, they need to show deep, element‑level detail people can actually trust. A traceable piece of data that’s observed over time is priceless if it’s readable and digested first from a high level before getting into the nitty gritty. Most organizations simply don’t have the time or the people to build and maintain something this complex.

Data quality is one of the areas where internal builds struggle the most. KPMG’s 2026 Executive Survey makes it very obvious: 51% of organizations lack the AI talent required to scale, and 30% of in‑house models fail to reach production because the underlying data isn’t ready. Talent gaps and data readiness issues compound each other, and most teams underestimate how much domain expertise is required to replace or rebuild data management technology. These systems are built on established ontologies, metadata frameworks and knowledge bases that underpin how organizations govern and understand their data. Rebuilding the foundation internally is a major undertaking: it takes time, expertise, and engineering effort.

When you look at what proper data‑quality capabilities actually needs; rule engines, profiling, anomaly detection, monitoring, remediation workflows, and pipeline integration, it becomes clear why internal builds end up expensive, fragile, and slow to mature. Most teams don’t realize how much engineering and domain knowledge sits underneath these systems until they try to build them. Buying a solution gives a solid starting point from day one with regulatory controls, enforcement and auditability already built in, which is why most organizations decide to buy rather than build it themselves.

There were a number of themes that were obvious:

• Buying accelerates time to value. Commercial solutions reach production in weeks or months, while internal builds often take one to four years to reach parity, a gap Forbes notes most organizations underestimate before maintenance costs even begin.⁵
• Buying stabilizes cost. Maintenance cost grows faster than subscription cost and eventually dominates the total cost of ownership.
• Buying reduces execution risk. Gartner emphasizes that proven solutions reduce volatility. KPMG adds that 30% of internally built AI models fail to scale due to maintenance and integration challenges.
• Buying frees scarce talent. Organizations increasingly recognize that their engineers should focus on integration and innovation instead of rebuilding commodity capabilities.

“The consistent message across sources is that building should be deliberate, governed, and small in scope. It should be reserved for capabilities where learning, control, and differentiation compound.”

Where does building makes sense?

A buy‑first strategy does not mean don’t build. Several sources make a compelling case for building in specific circumstances.

Harvard Business Review argues that building organizational capability compounds over time.⁶ Internal builds create learning, adaptability, and innovation that purchased technology cannot replicate.

• It’s your organization’s core competency. You are a digitally native company who builds and integrates software. And if the capability is central to your overall business strategy and IP that is purpose built exactly for what you are doing. Just as the swim lanes of end-user roles are being blurred, so must our processes. Technical teams need to understand the business and the business needs to become data and AI literate. Without that, even a well-scoped build won’t succeed.
• If a capability defines how you compete, owning it matters. Bought features are shared with the market.
• Protect what makes you unique. PwC highlights that your advantage comes from your own data and the way your organization works.⁷ If those elements cannot be shared to a vendor, building or keeping the capability internally is the best choice.
• Take ownership of the connection layer Even when components are purchased, owning the integration layer gives the capability to evolve your architecture over time and ensures long-term adaptability.

Building is becoming more accessible. Hyperscayle argues that natural language coding and AI‑assisted development are shrinking the build barrier.⁸ The practical implication is that organizations should re‑test build estimates every six to twelve months.

The consistent message across sources is that building should be deliberate, governed, and small in scope. It should be reserved for capabilities where learning, control, and differentiation compound.

That split plays out predictably: cloud startups, AI product companies, fintechs, and other digital-native companies build because software is the business, while hospitals, pharma and life sciences firms, retailers, manufacturers, financial institutions, and government bodies buy because software supports a different core mission.

When considering whether to build or buy, ask yourself these questions

• Is this a part of your core competency?
• Will it advance your business strategy or just replace underlying components?
• Do I have experts in this space to build and maintain over time?
• Is the scope of what I’m about to build clear and well defined?
• Are there solution experts in the space already, what is the TCO comparison?

A practical framework for modern organizations

The most consistent model across Gartner, Product School⁹, HBR, PwC, and McKinsey¹⁰ is a three-part buy, build, or blend approach. A smaller set of frameworks frame this as a four-way choice by adding a ‘partner’ track, though it typically collapses into the same three levers in practice.¹¹

• Start with proven commercial solutions for core and commodity capabilities. Configure rather than modify. Prioritize interoperability and open standards.
• Build. Invest in custom development if it is central to your core business strategy or when there is no credible market option exists and the capability is strategically differentiating. Prototype before committing. Keep the portfolio small and governed.
• Integration is where value grows. Blend bought and built systems into a converged whole through APIs, shared data models, and strong governance. Gartner calls this the hardest part of any application program, and the research supports that view.

This model reflects how organizations across sectors are actually allocating their budgets and talent.

A phased approach for technology leaders

1. Map and tier your systems. Classify each capability as commodity, contextual or differentiating. Align this with a written buy‑first policy.
2. Consolidate and buy. Standardize the core on proven solutions. Retire redundant or home-grown tools. Negotiate terms and contract conditions.
3. Build the few. Fund a small, governed portfolio of custom builds only for validated differentiators. Use rapid prototyping to test value before scaling.
4. Blend and govern. Invest in integration, data governance, and vendor management. Revisit the build‑buy boundary every six to twelve months as technology evolves.

“Buy what accelerates your organizational needs. Build what defines your core competency and business strategy… Blend everything into a system or AI factory that can evolve.”

Closing thoughts

The build versus buy decision for your data strategy is a question of strategy, capability, cost, and focus. Unless what you are about to build is central to your core competency or key to your overall business strategy, you should be very cautious about building. The research is clear:

Buy what accelerates your organizational needs.

Build what defines your core competency and business strategy, and where you have in-house expertise now and in the future.

Blend everything into a system or AI factory that can evolve, and grow with technology and needs of the business.

That’s the balance I see in the organizations that get this right.

Susan Laine, Field CTO at Quest Software, contributed to this blog post. Read her Build vs. Buy series on LinkedIn.

Sources:

1. Forbes Banker, S. (2026). Rethinking the SaaS Apocalypse. Coverage of the February 2026 enterprise software sell-off driven by advances in AI-assisted development.
2. Retool Retool (2026). The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software. Survey of over 800 professionals: 35% of enterprises have replaced a SaaS tool with custom software, and 78% plan to build more in 2026.
3. KPMG KPMG LLP (2026). Build vs Buy for AI: Executive Survey and Commentary. Survey findings: 50% buy or lease AI, 29% mix, 12% build; 51% lack AI talent; 30% of in‑house models fail to scale.
4. Gartner Gartner Research (2025). Build vs. Buy Strategy: Top Principles for Enterprise Applications (G00823668). Introduces the Buy, Build & Blend model and reports that 76% of enterprise application spend goes to commercial and low‑code software.
5. Forbes Technology Council Singh, M. (2026). Build Or Buy? The AI Era Just Rewrote The Rules. Forbes Technology Council. Buy‑leaning practitioner perspective on build vs buy dynamics in the AI era.
6. Harvard Business Review Srivastava, S., Chatterjee, S., & Tanone, R. (2026). 3 Ways to Rethink Your Build-or-Buy Strategy. Harvard Business Review. Study of ~17,000 public‑firm transactions (2010–2025) examining when organizations should build vs buy capabilities.
7. PwC Baker, A., & Desai, S. (2026). How AI is Reshaping Software Valuations for M&A and Private Equity. PwC US. Analysis of defensibility drivers such as domain depth, proprietary context and workflow gravity.
8. Hyperscayle Hyperscayle (2026). The RevOps Tech Build vs. Buy Debate Has Changed. Vendor‑leaning argument that AI‑assisted development is shrinking the “buy” column and accelerating build feasibility.
9. Product School Product School (2026). Build vs. Buy Strategy in the Age of AI. Practitioner framework emphasising strategic alignment, time‑to‑value, cost, data/IP and integration.
10. Graph AI (McKinsey Framework Summary) Davis, T. (2025). Build vs Buy Framework: A McKinsey Analysis.ai. A third‑party blog summarising McKinsey’s decision framework; not an official McKinsey publication.
11. TheCodeV TheCodeV (2026). Build vs. Buy vs. Partner Framework 2026. Content‑marketing piece adding “partner” as a third strategic path and referencing McKinsey, Gartner and HBR.