Buy vs. Build, Train vs. Use
The same question, a new decade
Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.
Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.
For years, engineering teams have used a simple rule when deciding whether to build something themselves:
If it’s core to your product, build it. If it isn’t, buy it.
If you’re launching an online radio service, you don’t write your own authentication system. You grab something off the shelf. But you might build your own audio encoder, because streaming quality is central to the experience you’re selling.
The rule works because it forces you to be honest about two things: what actually differentiates you, and what is just table stakes. Everything that isn’t differentiated is a tax on your roadmap.
Shouldn’t we apply the same logic to AI?
The AI version of the same question
The temptation today is to treat “AI” as a special category that escapes the usual trade-offs. It isn’t. The question is the same, only the verbs have changed:
TABLE
If you’re building a product where the AI behavior is the product (say, a coding assistant, a medical triage tool, a fraud model on your own transaction data) then training, fine-tuning, or building bespoke tooling makes sense. That’s your audio encoder.
If you’re just trying to write code a bit faster, summarize a meeting, or automate some internal busywork, you don’t need a custom tool. Use what already exists. That’s your authentication system.
“Wait” is a legitimate answer
There’s a third option the classic rule rarely needed, but AI does: wait.
The AI tooling market is moving fast enough that something you’d spend a quarter building today may ship as a feature of an off-the-shelf tool next month, often for less than the cost of one engineer-week. If the problem isn’t core and no tool exists yet, the cheapest move is often to do nothing, document the need, and revisit in a few weeks.
Not every problem needs a bespoke AI solution. Not every bespoke AI solution needs to be built now.
What this means in practice
Before greenlighting an AI project, ask three questions in order:
Is this core to what we sell?
If yes, investing in training, fine-tuning, or custom tooling is probably justified.If no, keep reading.
Does a good-enough tool already exist?
If yes, buy it, wire it in, and move on.
Your differentiation isn’t in the tool, it’s in using the time you saved.
If nothing exists yet, can we wait?
Usually, yes.
The cost of waiting is almost always lower than the cost of maintaining a half-built internal tool that a vendor will obsolete in six months.
Conclusion
The discipline that served us in the software world still applies. If anything, the speed of the AI market makes it more important, not less. Build when it’s core. Buy when it isn’t. Wait when the market is about to hand you the answer for free.
The companies that get burned in this cycle won’t be the ones who were late to AI. They’ll be the ones who built their own version of something they could have bought, or bought something they should have waited a month for.