Build vs. Buy and Why "I Can Just Build That" Is Costing The Business More Than You Think
When should you build vs. buy software solutions? Learn why "I can just build it" thinking usually costs more than commercial solutions and how to make smart technology decisions.
The motivation for this article came from a recent LinkedIn encounter with my former colleague, Kasper Lindgaard, now the founder of Aporio:
As you can see Kasper shared a provocative post about the never-ending debate in tech: should you build software solutions in-house or purchase them from the market? His post, discussing the common engineer mindset of “just scripting it in [insert any technology you choose],” struck a nerve with me because it’s a mindset I have observed repeatedly—and rarely with successful outcomes.
For starters, let me share a personal story.
When “Free” Becomes the Most Expensive Option
A while back, a software engineer reached out to pitch his project to me, which was a custom Application Security Posture Management (ASPM) solution. Of course, there was more to this story (no one builds an ASPM just for fun), and the full picture looked like this: his company needed to secure their software, looked at commercial options, and decided they were “too expensive.” So he decided to build one himself after hours, then his company deployed it for free, and he framed his arrangement as being a “design partner” (although to me, that seemed like a generous way to describe working for free).
Now, in order to secure ongoing support and maintenance for his recently developed ASPM, he wanted to take it to market and was looking for a partner or investor. One of the first questions I asked was this: “If your company wouldn’t pay for an existing ASPM solution because it was too expensive, then why would another similar company pay for yours?” This question might seem harsh, but it came from a place of sincerity.
Anyhow, as you may guess, he didn’t have a clear answer, as the economics of his own story contradicted the business plan. And I’ve noticed a deeper issue here.
Why Companies Buy Software (Hint: It’s Not Because They Can’t Build It)
At the beginning of working on any solution to the problem in tech, it’s easy to assume that “build it yourself” is free because you already know how to do that. However, the true cost of building isn’t in the actual building itself, but in the ongoing maintenance of the solution. Most of the time, this cost far exceeds the apparent price tag of vendor products.
So let me state frankly what many engineers fail to understand: you don’t buy software because you can’t build it. You buy it because maintaining, securing, and evolving it isn’t free, and it doesn’t make you money. In other words, it’s not your business.
But what is your business? Let’s say that we’re talking about a SaaS company building accounting software for small consultancies. Its core competency should be understanding accounting workflows, tax regulations, what makes bookkeepers’ lives easier, et cetera. Building own security solutions? That’s about as relevant to this business as baking own bread would be.
Which brings me to an important concept in economics that somehow gets lost in the “we can build anything” mindset: the division of labor.
The Economics of the Buy or Build Decision
Speaking of bread, could I bake my own? Absolutely! Would it be fresh, warm, and taste better than store-bought? Maybe. But here’s what I’d lose: the time and focus I could spend working on what I’m actually good at—helping companies secure their products.
So instead of baking bread, I buy bread. In this way, the baker is happy because they do what they like and know how to do well. I’m happy because I can also focus on things I like and know how to do well, while still having fresh bread. In short, we’re both better off because we’ve specialized.
Which makes so much sense that it is in fact the foundation of how the economy works. Yet in tech, I constantly see this principle ignored. Engineers look at a problem and think, “I could knock that out in a weekend.” But what they don’t calculate is:
The opportunity cost of not working on core product features that differentiate the business
The ongoing maintenance cost as dependencies update, security vulnerabilities emerge, and requirements change
The knowledge transfer cost when that engineer inevitably leaves and nobody knows how “that weekend project” works
The scale and reliability cost of running it in production at enterprise scale
When to Build In-House: A lesson from Boeing
Now, to be clear, I’m not advocating for outsourcing everything to the bone. The pendulum can swing too far in the other direction, and it has for various companies many times.
A prime example is Boeing, whose own experience demonstrates that the buy vs. build decision isn’t binary. When companies outsource core competencies (what makes them unique), they lose competitive advantage. Conversely, when they insist on building everything in-house, they waste resources on solved problems.
There is a balance to be found here, which requires understanding what is core to the business and what isn’t. And as it often is for such matters—it sounds easy, but it is hard.
For an elaborate critique of Boeing, read the excellent paper “Outsourced Profits – The Cornerstone of Successful Subcontracting”.
Why Engineering Should Advise, Not Decide
Engineers will almost always believe they can “just build it.” I don’t think it’s malice or arrogance—I think it’s professional optimism. You know what I mean—give me six engineers and a pizza budget, and we could build a basic version of most SaaS products over a few weekends. (Especially now with AI, am I right?)
But “can we build it?” is the wrong question to ask. The right questions to ask are:
Should we build it?
What’s the total cost over 3-5 years?
What core business value are we deferring to build this?
Who will own it when the original builder leaves?
What happens when it needs to scale 10x?
These are business questions that require business thinking, which in the long-term is a competitive advantage over those who think strictly in engineering terms.
BTW, I also don’t believe that this is an instance of NIH Syndrome, which in my mind is a separate, deeper issue.
Build What Makes You Unique, Buy Everything Else
The build vs. buy decision ultimately comes down to understanding your core business. Build the solutions that give you a competitive advantage (security is not it unless you’re a security startup). Buy everything else, even if you could build it. Focus your engineering talent on innovation, not on reinventing solved problems.
Getting this right isn’t just about saving money—it’s about strategic focus. Those who master it move faster, innovate more, and compete better.
P.S. If you’re interested in learning more about Kasper’s work, check out Aporio, where he’s building an enterprise identity intelligence platform.
P.P.S. Recent article by
also touched upon this subject with an excellent passage: “People who believe enterprises buy software only because they can’t build it in-house fundamentally misunderstand how large organizations operate.” You can read the full article here.