Build vs. buy was never really a binary choice. It was always a question about where your competitive advantage actually lives. Most companies are still answering it wrong.
Every technology decision eventually arrives at the same fork.
Do we build this ourselves or do we buy something that already exists? It sounds like a practical question. Budget, timeline, resources. A quick pros-and-cons list. A recommendation to leadership.
The problem is that framing it that way almost guarantees a bad answer.
Build vs. buy isn’t a procurement question. It’s a strategy question. And the companies that treat it like the former consistently end up either over-engineering things that didn’t need to be custom, or outsourcing things that were quietly central to how they differentiate. Neither mistake is cheap. Both take years to unwind.
What actually makes this decision hard isn’t the options. It’s the clarity required to make it well.
The Real Question Underneath Build vs. Buy
Most teams approach this decision by comparing features. Does the vendor solution do what we need? Close enough? Then we buy. Not close enough? Then we build.
That logic misses the point entirely.
The question worth asking isn’t “can a vendor do this?” It’s “is this capability one we need to own?” Those are genuinely different questions with genuinely different answers.
Thoughtworks draws a clean distinction here between commodity capabilities and differentiator capabilities. Commodity capabilities are things your business needs but that don’t set you apart. Payroll. Payments. Standard CRM functionality.
Plenty of vendors do these things well. Following their version of best practice costs you nothing strategically, because the process itself isn’t where your edge lives.
Differentiator capabilities are different.
These are the things that shape how you create value, how you serve customers, how you operate in ways your competitors don’t. Buying a third-party solution for a differentiator capability doesn’t just cost you control. It hands the vendor partial ownership of what makes you competitive.
The catch is that the line between commodity and differentiator isn’t obvious and it isn’t static. A capability that was a differentiator three years ago might be table stakes now. Something that looks like a commodity on the surface might be deeply embedded in a process that’s core to your model. Getting this categorization wrong is the most expensive part of the decision.
Why “We’ll Just Customize It” Is Usually a Warning Sign
The most common escape hatch when a vendor solution doesn’t quite fit is customization. Buy the platform, then bend it to match the business.
Sometimes that’s the right call. Often, it’s where the real cost begins.
Customization feels like a compromise. What it actually is, is a commitment.
Every customization creates a dependency. When the vendor releases an update, someone has to reconcile it against your modifications. When the vendor changes their API, your custom integration breaks. When the vendor gets acquired or deprecated, the problem lands entirely in your lap.
None of this is a reason to never customize. It’s a reason to be deliberate about what you’re customizing and why. The question isn’t “can we customize this to work?” It’s “how much of what makes this solution valuable will we preserve once we’ve shaped it around our specific processes?”
There’s also a subtler cost that rarely makes it into the TCO calculation.
Vendor solutions encode their own version of best practice. When you adopt one, you’re implicitly agreeing to adapt some of your processes to their model. For commodity capabilities, that’s usually fine.
For capabilities that sit close to how you work and how you differentiate, that adaptation has a strategic price. It changes behavior. It constrains how people work. And those constraints quietly limit you in ways that don’t show up in a feature comparison.
What AI Is Actually Doing to The Build vs. Buy Decision
The current conversation around build vs. buy has been disrupted by a premise that’s spreading fast: that AI-powered development tools mean everyone can build now, so nobody needs to buy anything.
It’s an appealing idea. It’s also mostly wrong.
Marty Cagan makes this point clearly.
The reason enterprise software is hard to replace isn’t the code. It’s the business rules embedded in it. Thousands of them, often undocumented, built up over years by people who are no longer at the company. Rules around compliance, pricing logic, approval workflows, edge cases in financial processing. These rules aren’t obvious. They’re buried in behavior. And the people who defined them are long gone.
A non-technical person with access to a vibe coding tool and a clear idea of what they want to build still has no idea those rules exist. Until something breaks in a way that’s expensive and embarrassing.
So AI tools don’t eliminate the build vs. buy question. They change the surface area of it. They make it genuinely easier to build lightweight, custom tools for specific internal workflows that don’t have complex rule dependencies. That’s real and it’s valuable.
But complex enterprise capabilities, the ones with compliance requirements, multi-stakeholder process logic, and audit trails, those don’t get simpler to build just because the tooling improved.
What actually changes is the third option. Not build. Not buy. Build on top of what you bought.
The MCP Protocol that Anthropic proposed is significant here. It creates a standardized way for software, including AI agents, to interact with enterprise systems. Which means buying a SaaS solution and then building intelligent workflows on top of it stops being a one-off integration project and starts being a repeatable pattern.
The future Cagan points to is one where companies buy the complex component services that handle business rules, compliance, and core data, and then build the connective tissue, the workflows, the agents, the custom experiences, on top of them.
That’s not build vs. buy. It’s build and buy, deliberately layered.
What the Evaluation Actually Needs to Cover
If the decision is being made well, it’s slower than most teams want it to be. And it involves more people than most teams think to include.
The feature checklist is the least important part of the evaluation.
Vendors know what questions are coming. They’ve optimized their demos for exactly those questions. What’s harder to fake is everything else.
How the vendor approaches their own roadmap. Whether they’ll share it honestly, including the parts that are uncertain. Whether their development philosophy matches yours closely enough that you can actually work with them when things break. How they handle security incidents. What their support model looks like at 11pm when something goes wrong in production.
These things don’t show up in a feature comparison. They show up in reference calls with existing customers, in proof-of-concept projects that go slightly wrong, in the specific questions that make a vendor’s sales team uncomfortable.
Technical requirements deserve their own evaluation thread, separate from functional ones.
Security posture, API quality, data accessibility, upgrade strategy, infrastructure requirements- these tend to get rushed or skipped because functional stakeholders dominate the process. Engineers who will live with the integration decision should be equal voices in it. A solution that impresses business users but creates a maintenance nightmare for the technical team is a bad solution regardless of what it does on paper.
Cross-functional evaluation also exists to surface conflicts that wouldn’t emerge from a single-team review.
The recruiting system that requires interviewers to register fixed availability blocks sounds fine until you realize it’s directly in tension with a consulting firm’s core operating model of scheduling flexibility.
That conflict only surfaces if the people living the constraint are in the room.
The Cost Calculation Most Companies Get Wrong with Build vs. Buy
Total cost of ownership gets calculated incorrectly almost every time.
License fees get the attention because they’re the number in the proposal. But they’re rarely the real cost. Implementation costs. Integration work. Training. The ongoing maintenance of any customizations. The developer hours spent on upgrades. The cost of data migration if the relationship eventually ends.
All of these get underestimated, sometimes genuinely, sometimes because the vendor’s ROI calculator is designed to make the deal look better than it is.
The ROI model also gets built for the capability as it exists today. Rarely for what the business will need from it in three years. If the strategy shifts, if the product evolves, if the market moves, the assumption underlying the ROI calculation changes.
The analysis needs to factor in that possibility explicitly.
A more honest framing is to build the cost model yourself, not with the vendor’s template. Include the realistic migration cost if you eventually want to leave. Include the maintenance load on your engineering team. Include the cost of the customizations you’re planning today, and a rough estimate of what it costs to carry them forward through two or three major vendor releases.
That’s a harder conversation to have with stakeholders. It’s also the only one that reflects what the decision actually costs.
When the Answer Is “Neither, Yet”
There’s an option that rarely appears in build vs. buy frameworks: extending what already exists.
Before committing to a new purchase or a new build, it’s worth asking whether the current solution could be modernized. Containerized. Given an API layer. Extended with additional functionality that closes the gap. Not because legacy is always worth saving, but because the real cost of replacement is routinely underestimated, and the real capability gap is routinely overestimated.
The industry moves fast.
An evaluation from eighteen months ago might look different today. Capabilities that didn’t exist in the leading platforms then might exist now. Pricing structures that made a vendor uncompetitive might have changed. A functionality gap that seemed unbridgeable might have been filled.
Re-evaluation isn’t a failure of the original decision. It’s what responsible capability management looks like.
Build vs. Buy Is the Wrong End Point
The decision gets made. The contract gets signed or the sprint gets planned. And then, quietly, everyone moves on to the next problem.
The mistake is treating the decision as closed.
Build vs. buy isn’t a one-time call.
It’s an ongoing question that the business should be revisiting at regular intervals as the market changes, the strategy evolves, the vendor landscape shifts, and the internal team’s capabilities grow or shrink. A decision that was right two years ago might be constraining the business today. A capability that seemed impossible to buy might be available now and better than what was built.
The companies that navigate this well aren’t the ones that make the right call the first time. They’re the ones that built enough flexibility into their implementation to make the second call without having to tear everything down to do it.
That’s the real point. Not build or buy. But staying positioned to change your answer when the answer changes.
