Build vs. Buy in the AI Era

I’m an aspiring futurist. Perhaps this is why I find myself considering the SaaS apocalypse almost daily. Will all these SaaS companies just become pre-AI era dinosaurs? Possibly yes. But mostly no. As I mentally go through all the software that companies use, there are truthfully not that many that I think will be replaced with an in-house solution.

This whole conversation is also not new. The “build versus buy” topic is one every tech company asks itself at least once. AI just makes the build side feel a lot more tempting. This brings me to my far-from-comprehensive, highly debatable Build vs. Buy table:

Even those in the “Build” camp will be bought

I also don’t believe everything here in my “Build” camp will definitely be built. These companies are going to try hard to find ways to keep their customers. And even if something would be possible to build, it might still make sense not to. For instance, penetration testing would be straightforward enough to do on your own. But for SOC2 and other compliance processes, you may need to show certification of completion. A homegrown test might not “pass.” With a website builder, if the website is relatively small, sure. But if it’s large, you probably don’t want to worry about bugs, SEO, templates, analytics, and all the other things that come with maintaining it. For a sales enablement tool, if you’re using it externally with customers, then you’re probably going to want to stick with it. But if you’re truly only using it as the source of truth for your collateral, AI could probably sub in.

Systems of record feel different

In terms of “Buy,” there’s definitely a theme around systems of record. I’m closest to Salesforce, and I have to say: I don’t think it’s going anywhere. I am very familiar with how to build things in Salesforce and all the dials and knobs on the backend. I think there is so much more there than people realize. To rebuild Salesforce would require thinking through and accounting for so many requirements: object and field customizations, permissions, workflows, integrations, admin controls, change history, and all the random edge cases every company accumulates over time. Obviously it’s possible. I worked at Google, and they did roll their own. While I was there they called it GRM, short for Google Relationship Manager. There was a whole team dedicated to developing and supporting the tool, and even then, it still wasn’t perfect. That’s what people underestimate: the initial build is only one part of the work.

I do think an upstart may steal share from Salesforce, but even that won’t happen overnight. It has to have the table-stakes functionality and flexibility that Salesforce has while getting everyone excited about its AI-forwardness. For instance, Gong recorded meeting transcripts before, but Granola came out and made a lot of people realize there could be a lighter, more AI-native version.

My build-vs-buy consideration set

Obviously, the classic build-vs-buy question is partly about whether something is strategic enough to own. I still think that matters. But with AI making the initial build feel easier, I think the more interesting question is whether you actually should own all the software you’ve been buying.

So I’ve distilled what I think the principles are for deciding whether something should be bought or built. I’ve come up with five dimensions. If it passes all five, then sure: build it.

Complexity: If it would take a lot of time and technical know-how to get all the requirements and details right, then buy. Otherwise, if it’s relatively simple to build and maintain, build.

Criticality: If it creates real risk when it breaks, then buy. If downtime or bugs would be annoying but manageable, building may be fine.

Permissions: If you don’t need to manage user access levels, great. Build. If you need one or two role types, maybe you can still handle it. But if you need multiple permission levels, then buy.

Integrations: If there are no integrations needed, great. Build. If the desired integration has an open MCP or an API, okay, maybe build. If the tool requires an integration that involves business development or is deeply tied into other business-critical systems, just buy.

Credibility: If you need an external certification, audit trail, or third-party stamp of approval, then buy. A homegrown version may work internally, but it may not be enough externally.

So, will today’s software companies become dinosaurs?

I wouldn’t start planning a dinosaur museum.

I think companies will build more of the lightweight, internal, low-risk workflows they used to buy. And they will still buy the systems where reliability, permissions, integrations, compliance, and maintenance matter.

The build-vs-buy question is still going strong. AI just made the answer more interesting.