Build vs. Buy AI: A Framework for Enterprise Software

AI has made it dramatically easier for companies to build their own software. I think that’s going to create a new problem: companies building far more than they should.

The cost of getting to a first version of almost anything has collapsed. A capable team can now prototype in weeks what might once have required a vendor. That makes building much more attractive. It can also make it look deceptively cheap.

A working prototype proves that you can build something. It doesn’t tell you whether you want to own everything that’s needed to make that capability excellent three years from now.

I’ve been thinking about this a lot as we build Surface. We’re talking with companies that have the technical capability to build a lot of this internally but are still choosing to buy purpose-built AI for the People function.

The decision usually isn’t “can we build something?” It’s whether they want to recreate and maintain everything around the model: the data infrastructure, integrations, benchmarks, evaluations, domain expertise, and ongoing improvement.

The same pattern is playing out across enterprise software. Companies buying Harvey in legal, Rogo in financial services, Gong in revenue, Clay in go-to-market, or Sierra in customer experience usually have strong engineering teams and access to the same frontier models. They could build versions of these products themselves.

The question is whether they should. I think companies need a clearer framework for making that decision. Here are a set of questions I think any company should ask if they’re going through a build/buy debate:

1. Is the capability itself a source of competitive advantage?

This is the strongest argument for building. If you’re a lender and your proprietary underwriting logic is fundamental to how you outperform competitors, you probably want to own it.

If you’re a marketplace and the way you rank supply, price inventory, or match buyers and sellers is core IP, you probably want to build around that.

Sometimes the answer is much simpler. An engineer might build a lightweight internal agent to automate a strange, company-specific process because buying a product to solve it would be overkill. But “our process is unique” is not the same as “we should own the tech stack.”

The core question is: which part actually creates differentiation? A law firm’s legal judgment may be differentiated. That doesn’t mean the firm needs to build its own legal AI platform. Identify the layer you need to own.

2. What does the vendor have that you can’t easily recreate?

It can be easy to compare your internal prototype to the visible interface of a product rather than everything underneath it.

Take Clay. The value isn’t simply “an AI agent that researches prospects.” Clay gives companies access to a broad data and enrichment layer, external signals, web research, orchestration, and integrations across the GTM stack.

You can absolutely build an agent that researches a company. Recreating the data infrastructure underneath it is a different project.

There’s another category of value that I think is especially important for enterprise AI: creating structure and meaning out of a company’s own data.

Glean, for example, builds an Enterprise Graph that maps the relationships among people, content, projects, teams, and workflows.

We’re taking a similar approach with Surface for the People function. Connecting an HRIS, ATS, performance system, engagement platform, and company documents gives an AI system access to a lot of information. But access isn’t the same as understanding.

Surface builds a company ontology that gives those inputs meaning: how teams relate to one another, how roles and levels work, which populations are critical, how performance is defined, how promotion decisions are made, what talent practices the company says it follows, and how those pieces connect.

Then we add context the company can’t generate internally: proprietary benchmarks, external market signals, talent-practice data, and frameworks developed through work with more than 2,000 organizations.

Any company can put its own HR data into an LLM. But that’s meaningfully different from giving the LLM a structured model of how the organization works, plus data and expertise that exist outside the organization.

That difference should be part of the build-vs.-buy calculation.

3. Does quality depend on domain-specific judgment and evaluation?

Creating a working demo is pretty easy. Knowing whether the system is consistently right is harder. This matters enormously in domains where a plausible answer and a good answer are not the same thing.

Harvey has built benchmarks around legal work to compare how frontier models and different agent architectures perform on real legal tasks. Sierra similarly evaluates different models and system designs for customer-service work. That work is mostly invisible to the end user, but it’s a huge part of what you’re paying for.

Another layer here is expert judgment. Abridge is a good example in healthcare. A hospital could build an AI system that turns a patient conversation into a clinical note. But producing a transcript is different from knowing what information is medically relevant, how it should be documented, and whether the resulting note meets the standards a clinician would apply.

We think about Surface similarly. Answering a workforce question isn’t only a retrieval problem. The system needs to know how an experienced People leader would investigate it: which populations to compare, which internal and external signals matter, when a benchmark is relevant, what competing explanations to test, and what evidence should change the recommended action.

For us, that judgment comes from twelve years of working through these questions with more than 2,000 organizations. We can encode more of it into the product every time we improve the way Surface approaches a problem.

Recreating the visible output is different from recreating the accumulated domain judgment behind how a great system reasons.

4. Does the product get better because it serves many companies?

Some capabilities become better primarily by learning your company. If that’s true, it may favor building.

Others improve because the same class of problem is being solved over and over across many organizations. That creates a meaningful advantage for buying.

Gong can invest in understanding revenue signals across billions of buyer-seller interactions. Sierra can continuously improve model routing, simulations, monitoring, retrieval, and reliability because those investments benefit customer-service agents across its customer base.

The same dynamic applies to domain expertise. A purpose-built vendor can keep improving how it approaches a particular class of problem because it sees variations of that problem repeatedly.

An internal team can make a system highly specific to its own business. A vendor spreads the cost of learning, evaluation, and improvement across an entire market. The more valuable that compounding learning is, the stronger the case to buy.

5. Are you comparing the full costs?

This sounds obvious, but I see companies make this mistake all the time: count the vendor contract but not the internal resources required to build the alternative.

Start with the cost of getting to v1. How many engineers will it take? How much time will domain experts spend defining requirements, testing outputs, and correcting failures? Does the project also require data engineering, product management, security review, or design?

The cost isn’t only the salaries of the people doing the work. It’s the other product, data, or business priorities they aren’t working on while they build this one.

Then include the ongoing costs: maintaining integrations, handling edge cases, evaluating new models, managing permissions and security, monitoring quality, updating the system as the business changes, and continuing to improve it as the underlying technology evolves.

There are also direct infrastructure costs. If the system relies on frontier models, an internal build carries ongoing inference costs, along with things like retrieval, storage, observability, and evaluation infrastructure. A vendor price will often bundle much of that into the product.

Of course, buying has “hidden” costs too: implementation, integration work, change management, and vendor oversight.

The comparison should be between the full cost of owning the capability internally and the full cost of buying it.

6. Could we buy the foundation and build what’s distinctive?

Build vs. buy is often presented as a binary choice, but I think we’re going to see a growing number of sophisticated organizations pursue a hybrid option: Buy the infrastructure. Build your advantage on top of it.

Paul Weiss worked with Harvey to create custom workflows incorporating the firm’s own expertise, processes, and standards. We’ll continue to see examples like this, and in many cases, it may bring the best of all worlds.

TL;DR: I’m long vertical AI :) AI is making it possible for companies to build far more software internally, and they should obviously take advantage of that.

Experiment aggressively. Build prototypes. Invest deeply in the capabilities that are genuinely unique to the company. But when a purpose-built product brings data you don’t have, domain expertise you haven’t accumulated, evals you don’t want to maintain, integrations you’d otherwise have to own, and a learning curve funded across many customers, “we could build it” isn’t a very compelling argument.

Own the capabilities that create a competitive advantage. Buy the ones where someone else has a structural advantage in building them better.