Build vs. Buy for Platform Teams: The Hidden Cost of Internal Tools
Matthew Holmes
June 16, 2026 · // 9 min read
Every platform team runs the build-versus-buy math at some point. Build reads as a one-time cost with full control. Buy reads as rent you pay forever. On that comparison, building usually wins.
The comparison is broken. The build column is missing most of its rows. You priced the code, and the code is the cheap part.
You estimated two engineers for three months. What you signed up for is a product that someone owns for as long as it runs: documentation, onboarding, edge cases, integrations, support, and a stack that ages out from under you. None of that was in the estimate. All of it lands anyway.
For most internal platform tooling, buying costs less than building. A build estimate prices the code. The real cost is the years of maintenance, integration, support, and stack upgrades that follow. Over three years, building an internal tool often runs three to four times the cost of an equivalent purchased one. Build only for genuine competitive differentiators.
What does it actually cost to build an internal tool?
More than triple the estimate, and the gap is maintenance.
Start with the number a platform team writes down. Two engineers, three months, six engineer-months. Now run the tool forward. The first build ships in three months. Then one engineer carries maintenance from there on. Integration work with the rest of your stack runs another two months. Documentation takes a month. Support settles in at a few hours a week, every week. Feature requests arrive every quarter, and so do bug fixes and security patches.
Put real assumptions against it:
| Period | Engineer-months |
|---|---|
| Year 1 (build + integration + early maintenance) | ~10 |
| Year 2 (maintenance + features) | ~4 |
| Year 3 (maintenance + features) | ~4 |
| Three-year total | ~18 |
You estimated six. The model lands near eighteen. Assume a fully loaded cost of $200k per engineer and the three-year bill runs roughly $900k to $1.3M. An equivalent SaaS tool at $50k to $150k a year, plus a month or two of integration, runs $150k to $450k over the same window. In this model, buying comes out three to four times cheaper.
The inputs are yours to set. Change the salary, the team size, the support load, and the totals move. The shape holds. The build estimate counts the code and stops. The real bill is the decade of ownership after.
Across a three-year window, building an internal platform tool runs about three to four times the cost of buying an equivalent SaaS tool once maintenance, integration, and support are counted.
The five costs nobody puts in the estimate
The code is roughly one-fifth of the work of an internal tool. Documentation, integration, edge cases, support, and stack upgrades are the other four-fifths, and they arrive after v1 ships.
Product surface area. You think you are building a script that does one thing. You are building documentation, onboarding, error messages, edge-case handling, a migration path off the old system, a rollback plan, monitoring, and support for the people who use it.
The feature treadmill. v1 does one thing. Month two brings a request to support another case. Month four, a filter. Month six, an integration. By year two the tool does fifteen things, and nobody asked for a fifteen-function tool. The complexity arrived one reasonable request at a time.
The integration tax. An internal tool has to talk to GitHub, Slack, your CI system, your auth, your monitoring, and your ticketing. Each connection costs a week or two to build and a few hours a quarter to keep alive, and each one breaks on someone else’s release schedule. You set out to build a tool. You end up running an integration layer.
The support burden. Fifty teams adopt your tool. Each week brings how-do-I questions, bug reports, a feature ask, and at least one “this broke and I need it now.” Call it four to six hours a week. Across a year that is two to three months of engineering time spent answering for a tool before any new work gets done.
The aging stack. You built on the current major versions. A year later the framework ships a new major. The year after, your runtime hits end of life. Then a core dependency lands a breaking change. You are not maintaining features anymore. You are maintaining the whole stack underneath them, on its timeline, not yours. This is operational maintenance debt — it compounds silently until it demands full attention.
The bigger cost is opportunity
Eighteen engineer-months is not only money. It is the work those engineers did not do.
Spend eighteen engineer-months on a PR-coordination tool and you did not spend it on self-service provisioning, better observability, or the developer-facing platform work that moves your roadmap. The build-or-buy question is rarely about whether your team can build the thing. Your team can build most things. The question is whether this is the best use of the team you have. Cutting the commodity tooling your team owns is one of the few ways to scale platform impact and reduce engineering overhead without adding headcount.
Most platform teams answer it wrong because of one belief: our workflows are unique, so we need custom tools. Some of your workflows are genuinely yours. Most of them are the same coordination and maintenance problems every org at your size has. Building everything custom to handle the part that is actually different is how a team ends up owning a dozen tools, half of them with fewer than ten users, none of them on the roadmap anyone meant to commit to.
How do you decide whether to build or buy?
Score the call instead of arguing it. Run these five steps before you commit.
- Name the capability and what it would actually replace, including the manual coordination around it.
- Estimate the full three-year cost: build, integration, support, features, and stack upgrades, not the code alone.
- Score it on the five factors below, one to five each.
- Price an equivalent purchased tool, integration time included, against that total.
- Build only if the capability is a genuine competitive differentiator. Otherwise buy, and reassign the engineers.
Step three uses a simple rubric:
| Factor | Score 5 | Score 1 |
|---|---|---|
| Strategic value | Core competitive advantage | Common capability |
| Customization | Highly specialized to you | Standard workflow |
| Market options | No good alternatives | Several vendors |
| Team capacity | Real slack to spare | Already stretched |
| Maintenance load | Simple and stable | Complex and evolving |
Add it up. Above 20, building may be worth it. Between 15 and 20, look harder before you commit. Below 15, buy. Run this honestly and most internal tooling lands below 15, because most of it is a standard workflow with vendors available and a team that is already stretched.
Building still wins for some things: core platform abstractions, domain-specific orchestration, the work that is genuinely your competitive edge. Build those. The trap is spending that strategic budget on commodity coordination instead.
What should platform teams buy instead of building?
PR coordination, dependency upgrades, notifications, and status tracking across many repos sit squarely in the buy column. They are standard problems, vendors exist, and the maintenance load on a homegrown version is brutal. They are also the work that hurts most when it is missing, because the cost is not the code. The cost is coordinating a small change across dozens of teams and hundreds of repos, chasing PRs, and tracking who is done.
Tidra is an AI coding agent for both implementation and coordination of code changes across your organization. It applies one change across many repositories at once, including dependency upgrades, runtime migrations, and config updates, and delivers each as a reviewable pull request rather than an auto-merge. That coordination layer is exactly what a build-it-yourself version turns into the integration layer and support queue described above.
A platform engineer we work with priced a single coordinated change this way: “It’s taken the team weeks to tackle one issue. With Maintenance Agent, I can create a PR for everyone for about $10.” That is the number to hold against eighteen engineer-months of owning the equivalent tool yourself.
Buying is not free of cost either. You spend integration time. You depend on a vendor’s roadmap and uptime. You give up some control over how the thing works. Tidra in particular is not autonomous. It proposes a plan and generated code, you review the diffs and iterate, and nothing opens as a PR until you decide it is ready. That is the honest shape of the trade. You take on a dependency and a review step, and you hand back the decade of ownership. As a head of platform engineering told us: “No more spreadsheets, no more chasing PRs, the real value is in the coordination.” That line item is the one the build estimate never captures and the one that costs the most to carry by hand.
Bottom line
You can build almost anything your platform team needs. That was never the question. The question is whether the thing in front of you earns eighteen engineer-months of ownership, or whether that budget belongs to the work only your team can do.
For the commodity coordination layer, the answer is usually the same. Buy it, and put the engineers back on the roadmap. The next time a build-or-buy estimate for an internal tool crosses your desk, add the one number that never makes the slide: who owns this in year three, and what did they not build to keep it running?