SaaS Replacement: What It Is, When It Pays, and What Not to Replace

This is a practical guide to the decision. For the deeper argument about why owning this layer is the foundation of everything else, read Own the Plumbing. For where it sits in the larger picture, see Sovereign Growth.

What is SaaS replacement?

Most mid-market companies run on dozens of subscription tools, each renting them a slice of their own operation. A CRM that dictates how a deal moves. A ticketing system that decides what a support case can and cannot be. A dozen point tools stitched together by exports and manual re-entry. Each one is a small monthly bill and a small monthly compromise, and nobody has ever added up either. Stack audits keep finding the same thing: as many as half of purchased SaaS licenses go unused.

SaaS replacement is looking at that stack whole and asking a question the renewal cycle never lets you ask: which of these should we own instead of rent? For the workflows at the center of the business, ownership means a system built around your process rather than a vendor's template, holding your data in a database you control, enforcing permissions you set, and changing on your timeline instead of a product roadmap you do not vote on.

The point is to own the workflows that make you money and keep renting everything else. Owning more software for its own sake is not the goal.

When does SaaS replacement make sense?

There is a sweet spot, and it is the middle of the market: companies roughly $20M to $200M in revenue. Below that, ownership rarely pays. There are too few seats and too little software spend for the math to work, and renting is the right call. Above it, decades of configuration are sunk into the big platforms and every change routes through a committee, so escape is expensive even when it would help. In the middle, spend is high enough that ownership pays for itself, the sunk configuration is shallow enough to walk away from, and the owner is close enough to the work to make the call.

Inside that band, a few signals tell you a specific tool is a candidate:

• Per-seat pricing that punishes growth. When adding people to a workflow costs more than the workflow is worth at the margin, the pricing model is working against you.
• Workflows contorted to fit the vendor. If your team runs a workaround because the tool cannot represent how you actually operate, you are paying to be told how to work.
• Data trapped behind export limits. When you cannot get your own information out cleanly, or an API meters access to it, the vendor owns something that should be yours.
• A renewal date you can use. A large license coming due is leverage. It sets a natural deadline and frees budget that can fund the replacement.

None of these is decisive alone. Together they mark the tools worth putting on the list.

What should you never replace?

This is the part that earns the rest, and getting it wrong is how SaaS replacement gets a bad name. Some systems should stay rented, permanently, and the honest version of this work says so out loud.

Never replace your general ledger, your payroll rails, your cloud infrastructure, your security tooling, or your developer tools. These are commodities sold at a scale you cannot match, maintained by teams larger than your entire company, and they work. Building your own version is a way to set money on fire and call it independence. Replacing them would be malpractice.

The rule extends to any system of record that genuinely works. If a deep platform holds years of history and unwinding it would hurt more than the friction it causes, it belongs on a watch list, not a build list. Ownership is about control where control pays, not construction for its own sake. Keep the systems of record that work. Replace the painful workflow layer around them.

How AI changed the build-vs-buy math

For twenty years the build side of build-vs-buy was a trap, and everyone who got burned got burned the same way. Building custom software meant hiring a dev shop, writing a spec that ran to hundreds of pages and was wrong by the time it shipped, and then being held hostage for years by the only people who understood the code. Buying a subscription was slower death but safer death, so companies bought.

That calculation reflected the economics of building software before AI, and those economics were genuinely bad. They have changed categorically, not at the margin. The cost of building and maintaining owned software has fallen far enough that the old math no longer describes the decision in front of you. Small senior teams now ship and maintain systems that used to require a dev shop and a multi-year contract, and they maintain them without the company becoming a hostage to them. The failure mode people remember was real. It was also a product of its era, and the era is over.

This is why "custom software burned us last time" is usually true and no longer relevant. The scar is real. The conditions that caused it are gone.

What does the ROI look like?

The distinguishing feature of SaaS replacement done right is that it is funded by the subscriptions it retires. You are already spending the money. Redirecting it from renting a workflow to owning one does not require new budget, which is what makes the decision different from most software projects that ask for a check up front against a promise.

The structure can be better than budget neutral. Fees can be held until the license being replaced actually comes due, so the spend does not double up during the transition. If a system renews in the fall, the work is timed and billed against that date, and what the business pays is anchored to what it was already going to pay the vendor.

The rule underneath every version of this is simple: ROI positive, or we walk. If the numbers do not clear that bar, the replacement should not happen. That discipline is also the best protection against the old failure mode, because a project that has to pay for itself cannot quietly become a money pit.

(Structure only. The point is how the return is shaped, not a price.)

How to start

Start by inventorying the stack whole. Most companies have never seen the full receipt, because the bills arrive on different dates, sit in different budgets, and never get added up in one place. Put every live subscription on one page with its annual cost. The total, and the long tail of half-forgotten tools underneath it, is usually the moment the decision becomes obvious.

Then filter for what you are right to rent. Set aside the ledger, payroll, cloud, security, and developer tools with the reasons attached. Park the deep systems of record that work on a watch list. Strip out subscriptions already winding down and the small-dollar tail that is not worth anyone's attention. What remains is a much shorter list of real candidates.

Last, look for clusters. The biggest returns are not one tool swapped for one build. They are the places where a single owned system replaces several tools at once, because the same work was smeared across all of them. A customer journey spread across six systems that do not talk to each other is six line items on the receipt and one system waiting to be built. Find those, and the shortlist of dozens collapses into a small handful of builds.

For the full argument on why this first move is the foundation the rest of the strategy stands on, read Own the Plumbing.

Frequently asked questions

Is SaaS replacement the same as building everything in-house? No. It targets the workflow layer where a vendor's template is costing you money or control. Infrastructure, systems of record that work, and commodity tools stay rented. The goal is to own what differentiates you and rent what does not.

Will replacing SaaS actually save money? It should, or it should not happen. The work is funded by the subscriptions it retires, and the discipline is ROI positive or walk away. Beyond the direct savings, ownership removes per-seat penalties and export limits that quietly tax growth.

How is this different from SaaS consolidation? Consolidation reduces the number of vendors, often by standardizing on one big platform. Replacement changes who owns the workflow. You can consolidate and still rent your entire operation. The two can overlap, but only replacement gives you control over your data, permissions, and pace of change.

What size company is this for? Roughly $20M to $200M in revenue. Smaller companies rarely have enough seats or spend for ownership to pay. Larger ones have too much sunk configuration to move easily. The middle is where the math and the mandate line up.

We got burned by custom software before. Why would this be different? The failure you remember came from pre-AI economics: a dev shop, a giant spec, and years of dependency. The cost of building and maintaining owned software has dropped enough that small senior teams now do what dev shops could not, without leaving you hostage to the code.