When to Build vs. Buy Internal Software (And When to Just Prototype It)

Build internal software when it touches a real differentiator, you can commit engineering time to own it for years, and the five-year cost of maintaining it beats renting. Buy when it's a commodity function with no competitive edge. There's a third lane now too: prototype it fast with AI or no-code tools, expect to throw it away, and never let it touch sensitive data or become load-bearing infrastructure.

Most teams don't have a rule for when to use that third lane. This is the framework.

The old build-vs-buy binary is dead

Build-vs-buy used to be a procurement conversation. Now it's a daily decision made by whoever is annoyed enough with their current tool to open an AI coding assistant. Retool's 2026 report found that 35% of enterprises have already replaced at least one SaaS tool with a custom build, and 78% expect to build more custom internal tools in 2026.¹ Sixty percent of respondents say they've built software outside IT oversight in the past year, and a quarter do it regularly.¹

The economics of "buy" haven't gotten simpler either. Zylo's 2026 build-vs-buy analysis found that both build and buy total cost of ownership are routinely underestimated by 2 to 3x, and a $200,000 internal tool can carry a five-year TCO near $750,000 once hosting, maintenance, and compliance work are counted, roughly in line with an equivalent SaaS contract over the same period.² The difference is that the SaaS number shows up on one invoice. The built tool's cost is scattered across cloud bills, headcount, and Jira tickets nobody labels "maintenance."

So the binary was never that clean, and now there's a third option sitting between build and buy: AI-assisted prototyping that costs almost nothing to start and almost nothing to abandon. The skill isn't picking build or buy. It's knowing which lane a given tool belongs in before you start.

Why is everyone building their own internal tools now?

Three forces converged at once.

1. Builders aren't developers anymore. In Retool's 2025 builder survey of 1,128 respondents, only 35% identified as engineers; the rest were operations leads, product managers, analysts, and finance staff shipping production tools.³ Forty-eight percent said they can build a solution directly without waiting on engineering, and 51% now solve problems in days or weeks instead of months or quarters.³
2. No-code adoption was already climbing. Gartner forecast that 70% of new enterprise applications would be built on low-code or no-code platforms by 2025, up from under 25% in 2020.⁴ AI coding tools didn't start that shift. They accelerated it.
3. The approved tools often don't cut it. A Cybernews survey found 59% of U.S. employees use unapproved "shadow AI" tools at work, rising to 93% among executives and senior managers, and three-quarters of them admit to sharing sensitive data with those tools.⁵ Only 33% say the company-approved tools actually meet their needs.⁵ People aren't routing around IT out of malice. They're routing around IT because the sanctioned option is slower or worse, and now they have a way to fix that themselves.

Our guide to building internal tools with AI covers the mechanics of that shift in detail. This piece is about the judgment call that has to happen before anyone opens a builder at all.

The hidden cost of building the wrong thing

Building fast doesn't mean building free. The bill just shows up later, in a different budget line.

Developers already report spending 13.5 of a 41.1-hour work week addressing technical debt, and estimate they waste 17.3 hours weekly on legacy-code maintenance they'd rather not be doing.⁶ Gartner has projected that by 2025 companies would spend 40% of their IT budgets simply maintaining technical debt, and U.S. companies collectively spend an estimated $85 billion a year keeping bad technology alive.⁷⁶ Every fast build that becomes permanent infrastructure adds to that pile.

The AI angle makes this sharper, not softer. MIT's NANDA initiative found that despite $30 to $40 billion in enterprise GenAI investment, 95% of organizations are getting zero measurable ROI, and only 5% of custom enterprise AI pilots reach production.⁸ Externally-built implementations succeeded roughly twice as often as purely internal builds, 67% versus 33%.⁸ Fast and cheap to start is not the same as likely to succeed.

Security compounds the risk. Veracode tested over 100 LLMs writing code and found 45% of AI-generated samples failed security tests, introducing OWASP Top 10 vulnerabilities, with no improvement in security as models got more capable at functional correctness.⁹ A tool that ships in an afternoon can carry a vulnerability that sits undetected for years.

The framework: 4 questions to ask before you build anything

Before any internal tool gets built, bought, or vibe-coded, run it through these four questions.

1. Is this a differentiator or a commodity? Thoughtworks frames this as the core question underneath every build-vs-buy decision: commodity capabilities are things your company needs but that don't set you apart, and they're usually best served by adopting vendor best practice; differentiator capabilities are how you actually compete, and those are worth the cost of custom control.¹⁰ Scope this at the capability level, not the whole system. Most "buy" decisions hide a differentiator buried inside a mostly-commodity package.¹⁰
2. Can you actually commit engineering time to own it? A prototype with no owner becomes an outage waiting to happen. If nobody is assigned to maintain it past the demo, it belongs in the disposable lane, not production.
3. How sensitive is the data running through it? Regulated data, customer PII, or anything with compliance exposure raises the bar sharply, because the cost of a mistake isn't measured in developer-hours.
4. What does the five-year total cost of ownership actually look like? Not the sticker price of a subscription or the hours to prototype something this weekend. Include hosting, one-third-time engineering upkeep, and compliance sprints, the way Zylo's worked example does, and compare that honestly against the SaaS alternative's five-year contract cost.²

Answer those four honestly and the tool almost always sorts itself into one of three lanes: buy it, prototype it fast and plan to discard it, or commit to building it as a real asset. Our piece on how Fable 5.1 flips the build-vs-buy math goes deeper on the tipping point where a niche SaaS subscription starts costing more than the build.

What belongs in the fast-and-disposable lane?

This lane is for tools that solve a real but narrow problem, don't touch sensitive data, and won't need to survive past this quarter without a rewrite. Think:

• Internal dashboards pulling from a single data source for one team's weekly review.
• Glue code connecting two tools that don't talk to each other, with no compliance surface.
• One-off admin panels for a process that will change again in six months anyway.
• Approval or intake forms replacing a spreadsheet-and-email chain.

Retool's builder data backs this up directly: 80% of builders say they can now go from identifying a problem to shipping a solution without asking for engineering resources, and the majority doing that shipping aren't engineers at all.³ Platforms purpose-built for this lane, like Remy, let non-technical teams prototype and own these tools without opening a backlog ticket. The rule for this lane is simple: if it breaks, the fix is "rebuild it," not "page someone at 2 a.m."

What belongs in the build-it-right lane?

Some tools deserve real engineering investment because getting them wrong is expensive in ways that compound. This is the lane for:

• Tools that touch your actual differentiator, the thing customers pay you for.
• Systems handling regulated or sensitive data, where a shortcut becomes a liability.
• High-integration-density tools wired into a dozen other systems, where a fragile build breaks everything downstream.
• Anything with a multi-year horizon, where the true cost is amortized ownership, not a demo.

The McKinsey-Oxford research on more than 5,400 IT projects is a warning here, not a green light: large IT projects run 45% over budget on average, deliver 56% less value than predicted, and 17% go badly enough to threaten the company.² Speed at the prototype stage doesn't cancel that risk once a tool graduates to load-bearing. Our look at the end of the large software team covers how AI copilots change the headcount math for this lane, but the discipline required doesn't disappear just because one developer can now do the work of five.

Governance: the guardrail that makes fast building safe

None of this works without ownership and oversight, especially for the fast-and-disposable lane, which is exactly where most shadow building happens.

IBM's 2025 Cost of a Data Breach Report found that 63% of breached organizations lack a mature AI governance policy, one in five breaches tie back to shadow AI, and breaches involving high shadow-AI use cost $670,000 more on average than those with low or no shadow AI exposure.¹¹ Ninety-seven percent of AI-related breaches involved a lack of proper access controls.¹¹

That's not an argument against building fast. It's an argument for treating governance as part of the build, not an afterthought bolted on later. A workable minimum:

• Every internally-built tool has a named owner, even a disposable one.
• Anything touching customer or regulated data gets a security review before it goes live, given that 45% of AI-generated code fails security tests on the first pass.⁹
• IT keeps a lightweight registry of what's been built and by whom, rather than discovering tools during an incident.
• Tools that outlive their expected shelf life get re-evaluated against the four-question framework, not left running by default.

A one-page decision checklist

Before you start any internal tool, run through this:

1. Differentiator or commodity? If commodity, default to buy.
2. Owner committed? If no engineering time is allocated to maintain it, keep it in the disposable lane.
3. Data sensitivity? Anything regulated or customer-facing moves toward the build-it-right lane, no exceptions.
4. Five-year TCO, honestly counted? Compare against a real SaaS quote, not a sticker price.
5. Governance in place? Named owner, security review, and a registry entry before it touches production.

Run every internal tool through those five checks and the build-vs-buy-vs-vibe-code decision stops being a debate. It becomes a five-minute exercise, which is the whole point of owning your software stack instead of accumulating it by accident.