Last month, one of our engineers sat down during the trial of a developer productivity platform we were considering paying for, and rebuilt it. Not all of it. The 20% that actually mattered to us. Two hours later we had a dashboard sitting on top of our own Linear and GitHub data, doing what the trial did, only tuned to how we actually work. We cancelled the trial.
That’s when the math became unignorable.
I don’t think the “build vs buy” debate, as it’s currently framed, is a debate at all. It’s getting talked about as if AI has flipped the rule wholesale — every CTO’s stack up for grabs. I don’t buy that. Build vs buy was never a category-level question; it was always per-tool. What’s changed is that the answer has flipped for one specific category, and the entire trick is recognising which one.
The conventional take — build where you differentiate, buy where you don’t — sounds wise and tells you nothing. Every CTO already believes they’re building the differentiating bits. The question that actually helps is sharper: which tools sitting on your bill no longer earn what you pay for them?
The four buckets
Here’s the rubric I’m actually using right now, walking through our stack at a roughly 130-person scaleup with 45 engineers.
Bucket 1: utilities, aggregators, visualisers on top of data we already own. OKR tracking. Developer productivity dashboards. Project value visualisation. Anything whose core proposition is “we will collect data you already have and present it back to you nicely.” This is the bucket that just lost. The data was always ours; the only thing we were paying for was a bit of glue and a UI. With AI-assisted coding, the glue is now genuinely cheap. We’re consolidating three tools from this bucket into a single in-house equivalent — OKRs, dev productivity, and project-value tracking — written by one engineer in stolen hours during cooldown weeks.
Bucket 2: deep, mature, specialised functionality. Observability. Endpoint security. Anything where the product is the result of years of integration work, edge-case discovery, and operational learning we’d be silly to redo from scratch. We are not rebuilding our observability stack in a weekend, AI or no AI. We might shop around for a cheaper alternative, but the buy decision stands.
Bucket 3: tools whose value is data we don’t have access to. Industry benchmarks. Market intelligence. Anything whose moat is essentially other people’s aggregated data. We can’t generate this ourselves at any price. We pay.
Bucket 4: compliance and regulatory tooling. Our GRC platform has years of baked-in controls, monitor templates, role definitions, and evidence-collection logic. Replicating that, even with AI assistance, is a multi-quarter project that no auditor will rubber-stamp. We pay, gladly.
Three of four still get bought. Only one moved. The interesting thing is that bucket one represents a surprisingly large share of the typical company’s bill. Retool’s 2026 Build vs Buy Report, based on a survey of 817 builders, found that 35% of teams have already replaced at least one SaaS tool with a custom build, and that workflow automation, internal admin, BI, CRMs, form builders, and project management top the list of categories under replacement pressure. That maps almost cleanly onto bucket one.
The numbers, concretely
Abstract arguments lose to specific ones, so let me put the math on the table.
The dev productivity tool we trialled was around $50 per seat. We have ~40 engineers using it. Add the existing OKR tracker and we’re looking at roughly $20k a year, all of which we’re about to recover. Hosting the in-house replacement runs about €50/month: one Postgres instance, one container. Build cost so far: two hours of an engineer’s time, with maybe a couple of days more planned during a future cooldown to round it out.
I want to be honest about what we replicated. Not the product. The 20% of the product that delivered most of the value to us specifically. The vendor has years of polish on edge cases we may never hit. If we hit one, we’ll feel it. That’s the trade we’re making, eyes open.
The trap nobody’s talking about
This is where I’d push back on the cheerleading version of this take.
If you let your engineers build whatever they want, host wherever they want, with no one watching, you have not solved the SaaS sprawl problem. You have moved it inside your own walls and made it worse. There is no vendor invoice to cancel. There is no support contract to lean on. There is just a Postgres database somewhere in your AWS account that one engineer set up before they left.
Retool’s report itself flags that a lot of this building is happening “outside traditional enterprise guardrails,” which is a polite way of saying nobody knows where any of it lives. Forrester’s long-standing estimate that 80% of IT spending goes to maintenance is the cost of pretending governance doesn’t matter.
The non-negotiables I’d put around any internal-build effort:
- A clear owner per tool, named, the day it goes into use.
- SSO and proper authorisation. Not “internal-only, so we don’t bother.”
- Documentation. AI makes this cheap; there is no excuse.
- An offboarding checklist that includes “what tools did this person own, who’s taking them over.”
- Cost monitoring on the cloud accounts, because internal tools quietly spawn AWS bills too.
These aren’t extra. They’re the entry fee. If you’re not ready to put them in, keep buying.
Where this works, and where it doesn’t
I should be honest about the vantage point I’m writing from. We’re a 130-person scaleup with experienced engineers, a dedicated DevOps team, and a culture where engineers genuinely want to remove tools they find irritating. That makes building cheap and ownership feel natural.
I think this take applies even more strongly to bootstrapped startups counting every euro. It applies less, and differently, to enterprises where rolling out an internal tool means six months of bureaucracy. It applies poorly to teams without the infrastructure muscle to run their own services responsibly.
If you’re a small scaleup with a couple of senior engineers and a clean cloud account, this is straightforwardly available to you. If you’re not, do the audit anyway, but be more conservative about what you replace.
What to do this quarter
Open up your software bill. Look at it line by line. For each tool, ask which of the four buckets it falls into. The bucket-one tools — the aggregators, the visualisers, the glorified dashboards on top of data you already own — are the ones to interrogate hardest before the next renewal.
The shift isn’t that everything should be built now. It’s that a specific kind of vendor — the one whose moat was “we’ll collect and visualise data you already have” — has lost its moat. If your bill is full of those, a smaller, sharper stack is sitting there waiting for you. Just put the governance in first.
References
- Retool, The Build vs Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software, 2026 — retool.com/blog/ai-build-vs-buy-report-2026
- Forrester research on IT maintenance spend, summarised by Arena Solutions — arenasolutions.com
- BetterCloud, AI and the SaaS industry in 2026 — bettercloud.com/monitor/saas-industry
- TechCrunch, SaaS in, SaaS out: Here’s what’s driving the SaaSpocalypse, March 2026 — techcrunch.com
