Build vs Buy
The worst decisions don't fail on a spreadsheet, they fail when the loudest voice in the room answers the wrong question.
This time is a bit different, it’s turning into an essay but hope you enjoy the read.
There was this decision from a few years ago I’ve carried as a quiet regret, the call to build a custom solution rather than adopting an industry-standard managed service. At the time, the team treated it as a win, and I let myself be talked into the same view, even though something felt off. We finally walked it back recently. I wish I’d trusted that instinct sooner.
The story about making bad calls on build vs buy is never new. I’ve also seen the other side of the coin: teams that bought an expensive platform, used 40% of its features, then couldn’t unwind the contract when their needs changed.
It’s one of the most common decisions engineering leaders make, and one of the most consistent misses. This experience taught me an expensive lesson: it’s almost never because the math is hard. It’s because the question was framed wrong, or because the loudest voice in the room had the strongest preference, not the strongest reasoning.
I would like to break this into few chapters:
Why are we getting this wrong?
The questions that actually matter
What does this look like at different scales?
The traps that we watched people fall into
A practical way to actually decide
A closing honest thought
Why are we getting this wrong?
Before the framework, it helps to be honest about who’s pulling on what.
Engineers tend to lean towards Build. Building is more interesting than integrating. It’s better on your resume, and it carries a sense of ownership. I’m also guilty of this.
Leaders on the other hand, tend to lean towards buying. Buying spreads accountability. A vendor letting you down is an easier conversation than your team failing. Procurement feels safer than a headcount ask, and vendors are very good at making “Buy” feel like the obvious adult decision.
Vendors will tell you that maintenance is your real cost. They’re right.
Internal advocates will tell you that licenses compound forever. They’re also right.
Both can be true. The job is figuring out which one matters more for your specific situation, and not letting the people with the strongest preferences sway the decision.
The questions that actually matter
The wrong question is: “Is it cheaper to build or buy?” Cost matters, but it’s downstream of bigger things. Four questions move me more than the spreadsheet does.
Is this a core differentiating factor?
As engineering leaders, we need to be ruthless about where we spend our team’s cycles. If the business doesn’t care how a system works, they only care that it delivers data reliably, then you should default to “Buy”.
Take a data catalog. Engineering teams often want to build a custom internal discovery platform because stitching together metadata from the warehouse and transformation layers is a genuinely interesting technical challenge. But no business user cares about the elegant architecture behind your internal catalog. They just want to find their tables and trust their metrics so they can make decisions.
The data models and the insights they generate are your differentiator. The catalog is just the search bar. Buy the tool off the shelf, and keep your engineering cycles focused on building the data products that actually power the business.
Do we have team capacity and continuity for the next 3 to 5 years?
This is the question most often skipped, and the one that kills the most Build decisions.
Building is never expensive, owning it is.. Owning means on-call rotations, documentation, onboarding new engineers, security patches, dependency upgrades, and the slow drift of “the original team has all left and nobody really knows why this works.”
This one hits especially hard for stretched teams. If your engineers are already firefighting and context-switching, adding a custom-built system to their plate doesn’t save money. It just hides the cost in burnout and missed roadmap commitments.
If you can’t credibly commit to staffing the maintenance team for three to five years, don’t build.
Is our scale or constraint profile unique enough that vendors fail us?
This is the legitimate “Build” case.
If you process petabytes a day and the vendor’s pricing assumes terabytes, the math falls apart. This is when building makes more sense.
This is why hyperscalers (cloud services) build so much. At their scale, vendor solutions either don’t exist or cost more than building. There might be one, but hopefully it’s not an overkill for your business.
Notice the inversion, though: most organizations citing this reason aren’t actually at that scale. They’re using “scale” as a justification for a decision they already made for other reasons, where in reality it is never the case.
How reversible is this decision?
The best way to evaluate this is the “one-way vs. two-way door” framework. Two-way doors are reversible. If you don’t like what’s on the other side, you just walk back. They deserve a fast decision. One-way doors are practically irreversible and demand careful debate.
Buying a SaaS tool you can swap out next quarter is a two-way door. Hand-rolling a custom architecture that becomes the spine of your data stack is a one-way door.
The harder it is to back out, the more conservative your default should be. Always look for the two-way door first: Buy the tool, integrate it, and learn your actual edge cases. If it proves insufficient, you can still
“Build” later.
Living with a vendor solution for a year gives you the exact blueprint you need, making any future “Build” dramatically cheaper.
What does this look like at different scales?
The same framework lands in different places depending on where you sit.
Bigger organization build a lot because scale breaks vendors, they have the engineering bench, and the differentiation case is genuinely real for most of the stack. But even they don’t build everything. They buy CRMs, HR systems, and most of their corporate IT. The discipline isn’t “build everything.” It’s drawing the boundary clearly and resisting the urge to redraw it because a senior engineer fancies an interesting project.
Mid size companies usually do best buying about 80% of the data stack and building the 20% that genuinely differentiates them. The failure mode here is creep: each individual Build decision looks reasonable, but they accumulate into a homegrown stack the team can no longer maintain. By year three, half the engineering org is stuck keeping the lights on for tools nobody else uses.
SMEs should buy almost everything. The cost of context-switching between maintaining custom tools and delivering business value is brutal at small scale. The exception is when no vendor exists for the specific thing you need, or when the thing is so centric to your product. Otherwise: buy, integrate well, and focus your engineering energy on what your business actually does.
A useful gut check for smaller teams: if you have to ask whether you should build it, the answer is almost certainly no. Building should feel obviously right, not like a close call.
The traps that we watched people fall into
A few patterns show up again and again, regardless of company size.
The “we’re special” trap.
Almost every team I’ve worked with has, at some point, argued their requirements are too unique for any vendor. About 10% of the time this is true. The other 90%, the requirements are normal but emotionally familiar, which makes them feel unique. To solve this, get a third party opinion before betting on this.
The “open source is free” trap.
Self-hosting an open-source tool is not Buy. It’s Build with a head start. You still own the operations, upgrades, security posture, and the deep expertise required to debug it at 2 a.m. People treating it as a free Buy are usually about to learn an expensive lesson.
The “engineer ego” trap.
Sometimes a Build proposal is really a senior engineer asking for an interesting project, dressed up as a business case. This isn’t malicious. It’s human. But the cost doesn’t disappear because the motivation was personal. Ask: would we still want to build this if it had to be owned by our most junior engineer for the next three years?
The “outsource accountability” trap.
The mirror image: sometimes a Buy decision is risk-aversion in a suit. The vendor becomes the throat to choke when things go wrong, even when Build would have been the right call. Buying doesn’t make a project succeed. It just changes who gets blamed when it doesn’t.
A practical way to actually decide
When I’m sitting in front of one of these decisions, I work through something like this.
Sketch the three-year total cost of ownership for both paths.
Include people, not just dollars. For Build, count the engineers you’ll need to maintain it, not just ship v1. For Buy, count the integration work, vendor management overhead, and a realistic price increase at renewal. Most renewal increases are not 5%.
Write down what you’d need to believe for each option to be right.
If the Build case requires believing you can hire and retain three specialized engineers for five years, and you’re already struggling to fill the openings you have, that’s a signal. If the Buy case requires believing a particular vendor will still be competitive in three years, look at their funding, their churn, and how often they’ve been acquired in their category.
Talk to two or three peers who’ve made the same decision.
Not vendors, not your account executive. Actual engineering leaders who’ve owned the outcome. The hour you spend on those calls is more valuable than any analyst report.
Default to Buy unless Build is obviously the right answer.
This is the part most engineering cultures get wrong. The default in our industry is “we can build it” because we can. The question isn’t whether we can. It’s whether we should.
Build is the obvious answer.
There are times regardless of whether you want to buy or get a vendor to build it, after checking the vendor’s pricing and negotiations, the price just doesn’t make sense and you are asked to build it yourself.
We just had one recently! One of our most used services that we would like to procure, has a unique pricing mechanism and forces user-based pricing, rather than consumption-based. When it doesn’t make sense to buy while we can still survive after the above four questions, we can just continue to maintain it (and still cost less, with minimal maintenance).
A closing honest thought
The reason this decision is hard isn’t that the framework is complicated. It’s that the framework forces you to be honest about things that are uncomfortable: how special your team really is, how long your engineers will actually stay, how much you really know about your future requirements, whose ego is in the room.
When I was asked to build a framework around this, it mostly landed on a set of questions and with scoring on every question that contributed to whether to build or buy, the theme is almost the same, just different ways of asking and looking at the big picture.
I’m currently working with the best leaders I could ask for, who don’t have a bias toward one or the other. They have a bias toward asking the harder questions before either side wins the argument. Most of the time, the right answer becomes obvious once everyone in the room is willing to say what they actually think.
Irregardless as engineering leader, we should own whichever decision, clearly have the documentation on why such decisions were made, and when the “why” are no longer important or solved, it’s time to reconsider it again.