Build versus buy in the age of AI: Why the devil’s in the details

Something has shifted in the conversations with product and operations teams. A couple of years ago, the question was "Which tool would you recommend for this?" Today, it's "Do we even need a tool, or can we just build it ourselves?"

On the surface, that's a mature question – pragmatic, cost-conscious, exactly the kind of operational thinking I'd normally encourage. Except, more often than not, it isn't pragmatism talking. It's unchecked confidence. And the most expensive mistakes, in my experience, start as small wins.

The slippery slope of the small win

Let me describe what I'm actually seeing, because the discourse around build versus buy in software tends to play out in the abstract: AI-native startups disrupting the entire SaaS model, enterprises replacing their whole stack with custom LLM wrappers, CRMs quivering in fear as everyone builds their own. But that's not really what's happening on the ground.

What's actually happening is smaller and more specific. A product ops manager builds an automation that pulls data from one tool and pushes it to another. A product manager uses AI to synthesize a week's worth of user research interviews in twenty minutes. Someone gets tired of waiting for engineering to build a Slackbot and builds it themselves. A custom Jira integration gets stood up over a weekend. 

A lot of this is genuinely good. The democratization of building – the fact that people in operational roles can now do things that previously required engineering time, API knowledge, and a queue of tickets – is real and valuable. I'm not here to argue against it. In fact, I welcome it. 

But these small wins have one insidious side effect. They give people (usually leaders) permission to think bigger. And that's where the reasoning starts to slide.

"If my teams can build a Slackbot, why am I paying for a project management tool I only use half the features of? If AI can synthesize my research, why do I need a dedicated research repository? And actually, why are we paying for a CRM when we could just build something that fits exactly how we work?"

This is the jump we need to question. Because it feels logical, but it isn't.

What you’re actually paying for

When organizations buy SaaS, there's a temptation to think in output: You're paying for features. You buy a set of capabilities that help you do a thing. And if you can replicate those capabilities yourself – or get close enough – the subscription starts to look like an unnecessary expense. But that's not actually what you're paying for. It never really was.

When I pay for, say, a CRM, I'm not paying for contact records and pipeline views. I'm paying for a guarantee. I'm paying for a system that someone else has promised will not break, will comply with GDPR, will keep my customers' data secure, and will be maintained and improved over time by a team whose entire job it is to ensure that. 

That guarantee – the reliability, the compliance, the legal accountability – is the product. The features are just how it's delivered.

This is the moat that mature SaaS companies have built, and it's the thing that's hardest to replicate when you decide to do it alone. Because the moment you build your own, you become the guarantee. You become responsible for uptime. For data security. For GDPR compliance. For what happens when something breaks at 11 p.m. on a Friday and a customer's data is at risk. For the audit trail when your legal team needs one.

Most companies that ask, "Why can't we just build this?" are not asking whether they're ready to take on that responsibility. They're asking whether the features are doable. And in an AI-enabled age, the latter has become stunningly achievable by many. But it’s the answer to the first question that matters, and that answer is almost always very different from the latter.

The philosophical work nobody talks about

There's a second thing in the build versus buy debate being underestimated. It's subtle, but in some ways has more far-reaching and fundamental implications. 

Codifying how a business works – its processes, its data structures, its taxonomy, its semantics – is a genuinely hard thing to do. Not technically hard, necessarily, but it’s conceptually hard. It requires thinking carefully, almost philosophically, about what things mean, how they relate to one another, and what needs to be true for the whole system to be congruent with itself.

What counts as an active user? When does a lead become an opportunity? What's the difference between a task, a ticket, an epic, and a request in your organization? 

These questions sound simple. They are far from simple. And the answers have downstream consequences that compound over time.

SaaS companies have spent years working through these questions: The data models, the taxonomies, the workflows baked into mature products are the result of thousands of customer conversations, edge cases, and hard-won decisions about how business processes actually work in practice. When you buy a product, you're inheriting that thinking. 

When you build your own, you have to do it yourself, from scratch, usually without realizing the importance of what you're doing, and often at exactly the moment when you have the least time to do it well.

The aftermath looks like a homegrown system that works brilliantly for the team that built it and is incomprehensible to everyone else. It looks like data that can't be reported on because nobody agreed on what anything meant before they started. It looks like a tool that solved the problem it was built for and created three new ones in the process.

The hidden cost of everyone building their own thing

There's a dimension to this that we need to think about specifically through a product operations lens, because it's one that gets missed when individuals or teams evaluate their own build vs. buy decisions in isolation.

When everyone builds their own micro-tools, even when each individual tool is well-intentioned and solves a real problem, the cumulative effect is fragmentation. Teams optimize for their own workflow, their own data structure, their own way of naming things. And gradually, the organization ends up with a patchwork of bespoke solutions that don't talk to each other, can't be reported on centrally, and actively reinforce the silos that most leadership teams are desperately trying to break down.

Product operations, at its best, sits at the intersection of everything. It looks at the system of building, shipping, and learning from products as a whole, not as a collection of local optimization problems. And from that vantage point, the risk of everyone building their own thing is visible in a way it simply isn't when you're an individual product manager solving a problem for your squad.

Because the question is never just, "Does this solve my problem?" It's, "Does this make the whole system better or worse?" And that's a question that requires someone to be thinking about the whole system in the first place.

So, when should you build vs buy software?

Don’t get me wrong: None of this means that build is always the wrong answer. There are absolutely situations where it's the right one, and I'd encourage every leader to sit with that question before committing.

Build makes sense when your problem is genuinely unique to your context. When no available product does what you need, and the gap is specific enough that a bespoke solution is justified. It makes sense for low-stakes automations that connect tools together, reduce manual work, and don't carry significant data or compliance implications. It makes sense when you have the engineering capacity to maintain what you build, and the operational maturity to govern it. 

What doesn't make sense is replacing your organization’s infrastructure: The systems that hold your customer data, underpin your commercial relationships, or form the backbone of how decisions get made and progress gets tracked. In those cases, the guarantee matters. The philosophical work has been done. And the cost of getting it wrong is a broken business process, or worse.

The actual question in the room

The build vs buy software debate is ultimately a question about where to invest your organization's finite capacity. And the most disciplined version of that question isn't "Can we build this?" It's "Should we, and do we fully understand what we're taking on if we do?"

In my experience, the teams that answer that question well are the ones who think about their operating system as a whole: Not as a collection of tools, but as an interconnected system where coherence and shared context are what make everything else work. They're the ones who understand that buying isn't a failure of ingenuity or scrappiness. Sometimes, it's the most operationally intelligent decision you can make.

So build the automations. Build the connections. Build the small, specific things that only you need. But know what you're buying when you buy, and understand, very clearly, what you're signing up for when you decide not to.

eBook

The AI maturity gap:
Are product teams keeping up?

Read now