Article 5: Build vs. buy just got a lot more complicated
Here's a scenario that's playing out in boardrooms and founder conversations all over the world right now. A mid-sized company, let's say a regional food safety operator running forty sites, is using a piece of vertical software that costs them €30,000 a year. Their new head of technology comes in, opens up Claude, and says: "I reckon we could build something like this ourselves."
And they're not wrong. Not entirely. The prototype is genuinely impressive. It takes three weeks. The CEO gets excited. The CFO starts doing mental maths on €30k a year versus a one-time build cost. And then someone asks a question that changes the whole conversation: "What happens if it goes wrong?"
This is the build vs. buy question in 2026, and it's more nuanced than most people are treating it.
The vibe-coding moment
Let's give the in-housing case its due. AI-assisted development has made it genuinely easier to build software, faster and with smaller teams. Things that required a squad of engineers and six months of runway now have plausible paths to being built in weeks. For a company that's been writing fat SaaS cheques, this is naturally going to prompt a rethink.
And for some categories of software, in-housing makes sense. Internal productivity tooling. Lightweight reporting dashboards. Bespoke automation for internal processes that no off-the-shelf product handles well. If the stakes are low and the functionality is narrow, building it yourself is a reasonable call. But a lot of companies are applying this logic to software where it absolutely does not hold, and that's where it gets dangerous.
The risk filter
The question you need to ask before pressing the 'we'll build it' button is: what does this software actually do, and what's the consequence of it failing? There's a spectrum here, and it runs from low-stakes to existential.
At the low-stakes end, you've got things like internal scheduling tools, basic reporting, employee communication platforms. If your home-built version has a bad week and runs at 90% reliability, the impact is friction and frustration. Manageable.
At the other end of the spectrum, you've got software that sits inside regulated workflows: food safety compliance, EHSQ management, clinical records, financial reporting. These are not tools where 'good enough' is acceptable. If a food safety platform that previously worked 100% of the time now works 95% of the time, the 5% is not a UX problem. It's an audit risk, a regulatory risk, and potentially a liability risk. The cost of a single incident in a regulated environment dwarfs the annual SaaS subscription many times over.
The ACV threshold matters here too. If you're paying €5,000 a year for a piece of software, the calculus for in-housing it looks very different from paying €200,000 a year. At low ACVs, the ongoing SaaS cost is not really the problem. The opportunity cost of the engineering time, the maintenance burden, the version drift, and the accountability gap all conspire to make in-housing a bad deal even when it looks cheap on paper.
The accountability gap
This is the thing that I think gets underweighted in most build vs. buy conversations: when something goes wrong with a vendor's software, there is a vendor to call. There is someone accountable. There is an SLA, a support team, a contractual relationship that gives you recourse.
When something goes wrong with software you built yourself, you own it entirely. And in regulated industries, 'we built it ourselves and it broke' is a significantly worse answer to give to an auditor or a regulator than 'our vendor had an incident and here's how they resolved it.' The specialised knowledge embedded in good vertical SaaS is also easy to underestimate until you try to replicate it. The food safety platform that handles HACCP compliance isn't just a database with a nice front end. It encodes years of regulatory knowledge, edge case handling, and workflow logic that a team building from scratch will spend years rediscovering the hard way.
So where does this land?
Build for internal productivity, for genuinely bespoke problems, and for categories where reliability requirements are low and the failure mode is inconvenience.
Buy, and be glad you bought, when the software is embedded in a regulated process, when a failure has real-world consequences beyond annoyance, and when the institutional knowledge baked into the product would take years to replicate.
The 'we'll just build it ourselves' instinct is not irrational. In some contexts it's entirely right. But applying it uniformly across a software stack without filtering by risk profile is a mistake. And in regulated verticals, it's a mistake that can be very expensive to unwind.
Author: Yousif Hanna