Build vs. Buy for Internal Software: The Five-Option Decision
A decision guide for whether to keep paying for SaaS or build internal software - including the three options the build-vs-buy framing hides: renegotiate, switch, and consolidate.
CTOs, CFOs, COOs, and founder-CEOs weighing an internal build against a subscription - especially after AI-assisted development made building look suddenly cheap.
Use this when someone proposes replacing a paid tool with an internal build, or when a team built something useful with AI in a week and leadership is now asking what else could go.
Keep buying (renew or renegotiate)
The vendor moves faster than you could in a domain that keeps changing - compliance, integrations, security surface - or the true annual cost is small against the distraction of owning.
Confusing 'we've always paid for it' with a decision. Renewal-time evidence - seats, usage, overlap - should be checked annually even for tools you'll never build.
A renewal with corrected seats and a price cap, plus a documented reason this tool stays bought.
Switch or consolidate
The pain is price or fit, not category - an alternative vendor or a platform you already pay for covers the actual usage.
The feature-list comparison. Tools are switched on what teams actually use, which is usually a fraction of what either product sells.
A migration onto the alternative or the platform already paid for, with exit terms better than the contract you left.
Build and own
The workflow is stable and well understood, the vendor's moat is weak where it matters to you, the spend is material over five years, and a named internal owner exists - all four, not any one.
Pricing the build by subtraction: subscription fee minus build quote. Practitioner consensus puts true ownership cost at a multiple of the naive estimate once maintenance, dependencies, and staffing are priced - the build is the cheap part.
A five-year ownership cost model - build, run, maintain, staff, risk - approved before code, and a system with a runbook, monitoring, and an owner at the end.
How to make the call
- Step 1
Name the actual usage
Write down what the team truly uses the tool for, in a page. 'A form and three reports' at enterprise-platform prices is a build candidate; a deeply embedded system of record priced fairly is not.
- Step 2
Run the ownership screen
Stable workload? Weak vendor moat where it matters? Material spend? A named owner - not spare capacity? Regulated or compliance-heavy categories (payroll, core ledgers, benefits) fail the screen by default.
- Step 3
Price years two through five
Dependencies age, requirements drift, and the engineer who built it changes jobs. Model maintenance, refresh, and ownership staffing over five years. If the case only works with those lines at zero, there is no case.
- Step 4
Validate the AI discount on your own pilot
AI-assisted development genuinely accelerates internal tools - that's why this question is live. But the discount belongs in your model only at the rate your own pilot demonstrates, on your codebase, with your review standards - not at the rate a demo implies.
- Step 5
Decide what happens when the owner leaves
Key-person risk is the quiet killer of owned software. If losing one engineer strands the system, the design isn't done - and if there's no answer for who maintains it in year three, the decision isn't either.
Build vs. buy is a false binary, and the framing itself causes bad decisions.
The real menu has five options - renew, renegotiate, switch, consolidate, build - and the last one is reachable only after the first four are scored. Most tools that feel worth building are actually worth renegotiating; most sprawl that feels like a build opportunity is actually consolidation onto platforms already paid for.
What changed recently is real: AI-assisted development collapsed the cost of the first draft, and teams everywhere are discovering they can produce a working internal tool in days. In Retool’s 2026 Build vs. Buy report, 35% of 817 surveyed builders had already replaced at least one SaaS tool, and 78% planned to build more - concentrated exactly where vendor moats are weakest, in workflow automation and internal admin tools.
What didn’t change is the denominator. The engineering consensus - repeated across practitioner forums for a decade and louder now - is that the fully burdened cost of owned software runs a multiple of the naive build estimate, because maintenance, integration drift, and staffing dominate the total. The teams that regret building priced the subscription against the build. The teams that don’t regret it priced the subscription against the ownership.
That is the entire discipline this guide encodes: buy where someone else must keep pace with a changing world, build where the workload is stable and the need is yours - and put a named owner and a five-year maintenance line in the model before anyone writes code.
Where the decision turns into work
Office of the CFO
ARR waterfalls, board reporting, FP&A, unit economics, forecast accuracy, and finance infrastructure for technology companies scaling or preparing for exit.
Performance Improvement
Revenue, margin, delivery, technical debt, and operating-system improvement for technology firms with stalled growth or compressed EBITDA.
Frequently asked
- Hasn't AI made building basically free?
- It has made the first 80% dramatically cheaper - and left the expensive parts alone. Security, integration edge cases, monitoring, documentation, and years of maintenance were never the fast part, and engineering forums are full of teams discovering that the cost of building dropped while the cost of maintaining didn't. Treat AI as a real accelerant with an unchanged denominator.
- How much software spend justifies considering a build?
- As a screen, a tool needs to be material over five years - for most mid-market companies that starts around $50-100K/year for a single tool - before ownership math can beat a well-negotiated renewal. Below that, the winning moves are almost always renegotiate, switch, or consolidate.
- What kinds of tools pass the ownership screen most often?
- Internal workflow tools and administrative systems - the layer where vendors have the weakest moats and companies have the most specific needs. Survey data supports this: in Retool's 2026 survey of 817 enterprise builders, 35% had already replaced at least one SaaS tool with a custom build, concentrated in workflow automation and internal admin tooling.
- Everyone cites companies replacing all their SaaS with AI. Should we?
- The most famous version of that story is wrong as popularly told - the company at its center replaced major platforms with a mix of other SaaS and internal tools, and its CEO later said plainly that they did not replace SaaS with an LLM. The real lesson from every documented case is selectivity: consolidate broadly, negotiate hard, and build the few systems that pass a genuine ownership screen.
Articles that support the decision
BRIEF · TECHNICAL DEBT
The Margin That Wasn't There: Auditing AI Vendor Dependency Before You Sign
A SaaS target's 82% gross margin can hide a single-vendor API bill that quietly halves it. How to diligence AI dependency, model drift, and COGS before LOI.
349% Increase in AI Infrastructure COGS
BRIEF · TECHNICAL DEBT
The MLOps Audit: How to Price an AI Target Before the Models Quietly Rot
AI targets don't fail in the codebase—they fail in the retraining pipeline. A buyer's field guide to auditing MLOps maturity, model drift, and registry gaps.
400% Maintenance vs. Development Cost Ratio for Ungoverned AI
BRIEF · TECHNICAL DEBT
How to Diligence a GenAI Acquisition: Reading the CIM Against the Inference Bill
A PE diligence playbook for tech M&A: separate a real GenAI moat from a $25/month API wrapper, audit the IP chain, and price inference cost before you sign.
95% GenAI Pilot Failure Rate
BRIEF · TECHNICAL DEBT
The Brittle System Problem: When a Dashboard Tweak Takes Down Billing
A two-line change to a reporting page shouldn't crash your payment gateway. When it can, buyers cut the price. Here's how brittleness becomes a 22% discount.
22% M&A Valuation Discount Applied to Brittle Architectures
BRIEF · TECHNICAL DEBT
The End-of-Life Treadmill: How Dead Frameworks Sink SaaS Valuations
A frozen framework version is a diligence landmine. How SaaS leaders inventory end-of-life dependencies and run AI-assisted migration without freezing the roadmap.
EOL register first control for framework obsolescence
BRIEF · TECHNICAL DEBT
The 14-Month Billing Engine: How Series B SaaS Teams Build Their Way to a Lower Multiple
A Series B SaaS team built billing in-house to dodge a $50k vendor fee. The hidden cost: $850k in debt and a lower exit multiple. Here's the line to draw.
34% Engineering Capacity Lost to Custom Tool Maintenance