Build at the Surface. Buy the Infrastructure.
More thoughts on build vs buy in 2026.
I’ve written about build vs buy before. In retrospect, I think it was a little too academic. All the discussion of interfaces and the Innovator’s Dilemma didn’t really provide an accessible framework for helping GTM operators make build vs buy decisions.
I’d like to try again with a more practical metaphor: housing.
In our day-to-day lives, we rarely even have an option to build instead of buy (good luck vibe-manufacturing your next car). Housing, on the other hand, is one place where we actually encounter a build-vs-buy tradeoff.1
Buying an existing house means less effort up front, but you’re less likely to get exactly what you want. That’s generally how we view build vs buy in software.
The key thing to realize is that “build vs buy” is not a binary choice. Any functioning software system is a collection of decisions to build or buy. “Building” a house is the same way.
Unless you’re pioneering in the old west, you buy 2x4s; you don’t go harvest your own trees, set up a sawmill and make those yourself. Consider this infrastructure2—the things that must be right for everything else to work, but that aren’t unique to your particular house (or business).
The “build” most of us actually care about is the things that need to work a certain way for us to be happy—the layout, the design, the finishings. These are built on top of the infrastructure you choose. They sit closest to you and your stakeholders (the “users” of the house or the software). Consider these to be the surface.
When building houses and software, you should buy the infrastructure and you should build (or customize) the surface. The rest of this article explains why that is and—crucially—how to tell the difference between the two.
Buy the infrastructure
In our house analogy, infrastructure consists of the parts that make everything else work: lumber, pipes, wiring, concrete. They’re critical, but they’re largely the same across houses. We know we need them and we just assume we’ll buy them. Vanishingly few people mold PVC or smelt copper for their new home in the suburbs.
Software, on the other hand, is less concrete.3 We’ve all seen houses in various states of construction, but most people don’t see software come together in the same way. It just sort of… exists. So how do you decide if software counts as “infrastructure”?
Let’s look at an example.
Not too long ago I talked to a company building tools for high-frequency trading (HFT). They sell, essentially, speed. They offer everything from SaaS software to get prices and process trades in seconds to exchange-specific price data processing software built on special programmable chips—all so traders can shave nanoseconds off their trading times.
That is infrastructure software solving an infrastructure problem. These funds have all the money in the world to hire experts and their entire business depends on being incredibly fast. But even then, they’re still buying this tech because it’s the structural piece that everything else builds on.
So what makes a problem (and the software that solves it) infrastructure? Let’s look at it through the HFT lens:
High Enabling Specialization - very few people know how to integrate with pricing feeds and trading systems from hundreds of exchanges around the world; can keep up as those exchanges change those feeds; and have the technical know-how to manage systems that process those things in nanoseconds. This enables traders who want to execute those trades without caring precisely how those trades become bytes flowing over the network.
High Availability - in software, “availability” means whenever you need something to work, it’s ready to go. HFT systems simply can’t be down.
High Performance - this one is obvious in the HFT scenario because every nanosecond counts.
High Risk - HFT mistakes have crashed the stock market and cost one firm $10 million per minute, essentially bankrupting them in less than an hour. It’s hard to think of anything more risky that’s not actively life-threatening.
Applying these 4 categories to GTM shows us some of the infrastructure-level promises made by different types of GTM software:
Enabling Specialization - your dialer knows how to integrate with phone systems; your video conferencing system knows how to handle weird bandwidth issues; and none of these things are core specializations for your business
Availability - your sales engagement platform (SEP) and marketing automation platform (MAP) send emails 24 hours a day; your data syncs between systems run continuously; your chatbot shows up on your site; your calendar widget lets people book a meeting 24/7
Performance - your lead routing gets an inbound to a rep in seconds; your parallel dialer makes hundreds of calls at once
Risk - your CRM won’t lose all your data; your SEP won’t send hundreds of duplicate emails to your prospects
Of all of these categories, Enabling Specialization deserves a special callout because it’s been most impacted by AI.
SaaS companies exist to provide Enabling Specialization. It’s one of the reasons there are so many SaaS products. The idea is that they know more than anyone about one niche topic in the whole world. Buy their software and you’re automatically tapping into their expertise.
Unfortunately, this is also the category that AI has eroded the most. While it’s true that AI confidently pretends to know everything even when it doesn’t, it does actually know a lot about most things. A lot of “specialist” knowledge that previously lived in the heads of individuals—including how to build software in the first place—is now available for a few cents from an AI model.
It’s not just about specialist knowledge either; AI has made previously specialized technology widely available. For example, transcribing calls and extracting useful information from the text used to require highly specialized algorithms. Now anyone with Claude can do it.
None of that is to say there’s no such thing as meaningful specialization in software anymore—the HFT tech shows that’s not true—it’s just an ever-eroding target thanks to AI.
The Availability, Performance and Risk aren’t solved by AI. They’re solved by ongoing investments in infrastructure, monitoring, continuous iteration, and a willingness to accept contractual liability when things don’t work.
And that’s ultimately the reason you should buy at the infrastructure layer. These things aren’t differentiators for your business, just like 2x4s aren’t differentiators for a house. They’re things to build on top of, not things to build.
Build at the surface
When we build a house, the surface is the part we focus on. We work with the architect on the layout and design, then we pick out countertops, flooring, light fixtures, paint colors. We apply the finishing touches with appliances and furniture. Basically, we’re designing our house’s user experience to sit on top of all the infrastructure we already discussed.
When most of us think of “software”, this is what we think of: the way we interact with it, not necessarily the infrastructure underneath.
In the past week or so, I’ve gotten demos from three RevOps leaders of custom tools they’ve built to manage getting manager feedback on territory designs. One showed a complex Google Sheet and the two others showed Claude artifacts that clearly evolved from earlier spreadsheet-based iterations.
These particular tools are examples of what I mean by “surface” software. They’re highly-customized UIs built on top of and integrated with infrastructure capabilities like CRM, data warehouses, account routing and territory rules.
These tools gave sales managers the ability to tweak assignments and see the impact of variables specifically relevant to the business. They serve as a sort of translation layer, precisely translating the generic problem of territory design into the specific language and concerns of their internal stakeholders.4
Going back to the house analogy, these kinds of apps are the rug that really ties the room together.
So what makes a problem “surface”?
Core Specialization - every company exists to do something specific. The closer any given problem or piece of software is to your specific specialization, the more likely it fits into the surface you want to solve for.
High Human Involvement - humans make things complicated. They require enablement and they make mistakes. The closer something is to a pure user interface (like the territory feedback tools mentioned above), the more you’ll win if it’s tailored to your exact needs.
High Variability - when a process isn’t fully standardized it doesn’t make sense to lock it in with something that’s difficult or expensive to change.
Low Risk - when the monetary, reputational or legal risk of getting something wrong is minimal, the more freedom you have to build your own.
It helps to think of a couple of these as ends of a spectrum compared to the infrastructure categories. Specialization ranges from Enabling (infrastructure/buy) to Core (surface/build). Risk ranges from High (infrastructure/buy) to Low (surface/build).
The remaining ones—Human Involvement and Variability—sit at opposite ends of a spectrum from Performance and Availability from the infrastructure categorization. The more human and variable a problem is, the less you can guarantee performance and availability.
Anything that strongly fits these categories sits at the surface level. Nobody is going to offer something off the shelf that does exactly what you need. These are the problems you build solutions for.
Wrapping up
First, a word about the “messy middle”. Not everything fits perfectly within the infrastructure and surface categories.
One concrete GTM example is data enrichment. Amassing data used to be an enabling specialization but, as signals have gotten more nuanced, it’s become closer to a core specialization for GTM teams. It’s high variability, and close to humans, but it also needs to perform well across tens of thousands of data points. The risk is dependent on how the data is used, ranging from a few bad emails to a massive drop in pipeline from poor targeting.
This is why you regularly see “Clay is dead, Claude replaced it” and “you’re just wasting tokens to find X” posts on LinkedIn. It’s genuinely unclear how much of that problem should be build or buy.
Also beware of things that look like surface-level problems but are actually infrastructure problems. For a very small team, the CRM itself looks surface-level. It’s basically a glorified spreadsheet! But scale that team a little bit and it rapidly becomes infrastructure. This is why I’ve never understood the “everyone will vibe code their own CRM” narrative. The payoff just isn’t there.
AI has changed what’s possible to build. In doing that, it’s made build vs buy decisions harder because it’s made it harder to differentiate software based on Enabling Specializations. That means what used to be the most compelling reason to buy software is now one of the murkiest. You need to rely much more on the other factors—Availability, Performance and Risk—to get a clear infrastructure read. If it checks any of those boxes, buy.
That doesn’t mean you should build everything else. After all, vibe coded tools still take time to create and maintain. Focus on the things that are truly core and that genuinely unlock some kind of capability for your team that didn’t exist before. If it checks those boxes, build.
If you can afford it, that is.
It literally means the structure beneath.
I’m not sorry.
Incidentally, this is why spreadsheets are so hard to kill. They’ve been serving this translation role for years as sort of proto-vibe-coded apps.