Every "let's build it" decision is a decision to take on the permanent cost of being a software company for that capability.
That sounds obvious. It is not. In every build-vs-buy discussion I have sat in — across insurance, energy, reinsurance, industrial manufacturing — the framing is almost always the same: compare the SaaS subscription cost against the estimated engineering cost to build an equivalent, declare one cheaper, and make a decision. This comparison misses the actual question by a wide margin.
The vendor cost is a line item. The build cost is a commitment — to hiring, retention, security patches, API compatibility, regulatory updates, and opportunity cost — that compounds every year until you make a different decision. Most executive teams do not price the commitment. They price the project.
The Question Nobody Asks
When a team decides to build an internal CRM, a custom analytics pipeline, a homegrown identity and access management system, or a bespoke approval workflow — they are not just making a technology choice. They are deciding to become a software company for that capability.
That means:
- An engineer who owns the system, or a team that does
- A roadmap for keeping the system current as requirements change
- A security posture: patch management, vulnerability scanning, access controls
- Compatibility maintenance as the systems it integrates with evolve
- Documentation, onboarding, and knowledge transfer as the team changes
- An incident response process when the system is unavailable
None of this appears on the original build estimate. All of it appears on the three-year P&L.
The false economy of the internal tool
The most dangerous build decisions are for capabilities that "shouldn't take long." A two-week sprint becomes a system. The system gets dependencies. The dependencies get owned by engineers who leave. Three years later, the two-week sprint is a legacy system nobody wants to maintain and nobody has budget to replace. The original vendor that would have charged €15k/year is still running the same capability, updated and supported, for other customers' two-week sprints.
Where Build Decisions Actually Go Wrong
In my experience, bad build decisions cluster around three failure patterns.
The capability feels core but isn't. Engineering teams are drawn to building anything that touches the core product. "Our customer data is sensitive — we should control the storage layer." "Our approval workflow is unique — we need to own it." Sometimes this is true. More often, the sensitivity of the data is a reason to evaluate vendors carefully, not a reason to build. The uniqueness of the workflow is real but it is often 20% differentiation on top of 80% table-stakes functionality that a vendor has already solved. You build the 100% to own the 20%.
The estimate covers the project, not the product. Build estimates are written by people who are excited about solving the problem. They do not include: post-launch bug fixing, integration maintenance as surrounding systems evolve, security patch cadence, the quarter spent refactoring because the original approach didn't hold up at scale, or the two sprints lost to onboarding a new engineer to a system the previous owner barely documented. A build estimate that does not include a five-year operational cost model is not an estimate. It is a proposal.
The build is approved for the wrong reason. "We can build a better version." Maybe. Can you sustain a better version? A vendor's product is backed by their entire engineering team and their entire customer base funding improvements. Your internal tool is backed by whatever capacity is left after the real roadmap. In most enterprises I have worked with, internal tools are the first thing deprioritised under delivery pressure, and the last thing resourced for improvement.
The Framework I Actually Use
The build-vs-buy question I apply across client engagements has four tests. All four must pass for build to be the right answer.
| Test | Build is justified if... | Build is NOT justified if... |
|---|---|---|
| Differentiation | This capability is a primary source of competitive advantage | It is infrastructure, compliance, or operational plumbing |
| Sustainability | You have dedicated, stable engineering capacity to own and evolve it | It will be maintained by a rotating team or as a side project |
| Uniqueness | No vendor addresses this use case adequately | Vendors exist but the team prefers building |
| Total cost | 5-year build cost (including ops) is lower than 5-year vendor cost | The build estimate excludes operational overhead |
In practice, most internal tool requests fail test one. Most bespoke platform components fail test two. A surprisingly large number of "we need to build this" conversations fail test four once the operational cost is honestly modelled.
What "Becoming a Software Company" Looks Like in Practice
Let me make this concrete. I worked with a 600-person energy company that had built an internal developer platform — a thin Kubernetes abstraction with CI/CD opinionation and a service catalogue — rather than adopting a managed solution. At the time the decision was made, it looked reasonable: a three-month build, two engineers, a well-scoped problem.
By the time I engaged, three years later:
- The platform was maintained by one engineer (the other had left)
- It was two major Kubernetes versions behind because upgrades required significant rework
- Four development teams had stopped using it and were managing their own pipelines because it was blocking them
- A fifth team had escalated that its security posture was inadequate for a compliance audit they were about to face
- There was no roadmap, no product owner, and no budget allocated for improvement
The vendor alternative they had evaluated three years earlier now cost approximately €80k per year. The internal platform — when I counted FTE cost, opportunity cost, and the upcoming upgrade programme — was running at more than €400k per year and delivering less value.
The decision to build had never been revisited because nobody had made it in the first place. It had accumulated.
The accumulation problem
Most over-built internal systems were never a single decision. They were a series of small decisions — "let's add this feature," "let's not migrate to the vendor yet," "let's just fix this ourselves" — each individually reasonable. The build decision is usually irreversible by the time anyone recognises the cost. Which is exactly why the original decision needs to be made with a 5-year horizon, not a project horizon.
The Exceptions Are Real, But Narrow
There are genuine reasons to build. I have recommended build in situations where:
- The capability is genuinely core IP. A pricing algorithm at an insurer. A risk model at a reinsurer. A fleet optimisation engine at a logistics company. Here the competitive moat is real and the build commitment is proportionate to the value.
- The vendor market does not exist or is immature. In some specialised industrial domains, no vendor solves the problem adequately. Build is the only option, and the team knows it going in.
- Regulatory constraints make vendor options unviable. Specific data residency requirements, audit obligations, or sector-specific security mandates can eliminate vendor options entirely.
- The integration surface is too complex for any vendor to support. Where the capability must integrate across 15 internal systems in ways no vendor supports, a custom integration layer may be unavoidable.
Even in these cases, the framing should be: "We are deciding to become a software company for this capability. What does that commitment look like over five years, and are we prepared to resource it properly?"
What to Do With the Build Decision You Already Made
Most teams reading this are not making the build-vs-buy decision fresh. They are managing the consequences of a build decision that was made two or three years ago. Here is the framework for that situation.
Audit the actual cost. FTE time allocated to the system, incident and maintenance overhead, opportunity cost of features not built, and the cost of onboarding engineers to a system with limited documentation. Putting a real number on this changes the conversation.
Set a decision trigger. "We will revisit the make-vs-buy decision when the system requires a major upgrade, when the owning engineer leaves, or when maintenance cost exceeds €X per quarter." Without a trigger, the system perpetuates by inertia.
Define the exit path. What would migration to a vendor look like? What is the data portability situation? What integrations would break? Knowing the exit cost makes the stay-vs-go decision concrete rather than hypothetical. Most teams discover the exit is cheaper than they assumed.
Ring-fence the maintenance budget explicitly. Internal systems maintained from "slack time" do not get maintained. If the build decision was correct, the operating cost belongs in a budget line, not a margin. If it does not survive budget scrutiny as an explicit line item, that is information.
Build-vs-buy is the wrong frame. The right frame is: are we prepared to be a software company for this capability, at the cost that implies, for as long as we need this capability? Sometimes the answer is yes. More often, an honest accounting changes the answer.
If you are facing a significant build-vs-buy decision and want a second opinion from someone who has made and lived with both sides of this call, let's talk — book a 30-minute discovery call. I will give you a straight assessment of which side of the trade actually serves your business.