When Replacing SaaS With Custom Software Actually Pays

Somewhere in your stack is a subscription you have renewed three times and complained about every one of them. Your team has built a spreadsheet beside it to make it usable, and the renewal is coming up again.

This is a guide to working out whether that tool is worth owning instead of renting: how to find what you actually pay, what it really costs, what to try before you build, and what a replacement involves if you do.

What Is SaaS, and What Is the Alternative?

Software as a service means software you rent. It runs on the vendor's infrastructure rather than yours, you are billed per seat or per unit of usage, and your data sits on their servers governed by their terms. Your email, your CRM, your helpdesk, your accounting package and your project boards are almost certainly all SaaS.

The alternative is software you own. You hold the source code, it runs on infrastructure you choose, the data lives in your database, and no meter counts your users. Two things sit in between and get confused with both. Self-hosted open source means you own the deployment but not the roadmap. Platform services, the PaaS and IaaS layers underneath, are what you build on rather than what you buy finished. Our AI and ecommerce glossary has the fuller definitions.

Which Subscriptions Should You Keep Renting?

Three categories that almost always stay

• Infrastructure and ledgers, where cloud hosting, payroll, accounting and security tooling are someone else's core competence
• Commodity workflows like email, calendars and document storage, where a vendor's template is a shortcut rather than a compromise
• Any system of record your team does not fight, however large the invoice, because there is no friction to remove

What is left is the workflow layer

The tools that hold your process, your data and your permissions, and that your team has built workarounds for. The workarounds are where the hours go, and they are what you are really paying for.

How Do You Tell If a Tool Is Worth Replacing?

Two questions sort the shortlist. First, how much friction does it cause, measured in work your team repeats by hand rather than in how much they dislike it. Second, what would it cost to unwind, counting integrations, history and downstream reporting.

Low friction is a keep whatever the invoice says. High friction with a clean exit is a genuine candidate. High friction with a decade of history is usually still a keep. And when a tool cannot represent how you operate, someone builds a workaround beside it, which given enough time becomes the real process. That is the clearest signal there is.

What are the signs a tool should go?

A genuine candidate shows several of these at once. Any one of them on its own is just a bad quarter.

• Your feature requests have been open for years while the releases go elsewhere
• Nobody internally can say what it is for or who still needs it
• Every connection to your other systems is one you built and now maintain
• Per-seat pricing means the bill grows fastest when the business is going well, which is why the software companies expected to come through the current shake-out are moving off it
• A large renewal is coming, which is leverage, a deadline and freed budget in one event
• You have a compliance or data residency requirement the vendor cannot satisfy, which is the one signal that outranks all the others

Count them. Three or more and the tool is worth costing out properly. One or two and the faster fix is usually the specific thing that is wrong: a renegotiation, a tier change, an integration someone should own. The compliance case is the exception, because on its own it is already enough.

Which one do you do first?

If several tools qualify, rank them on two axes rather than by price. How central is the workflow to how you compete, and how hard would the switch be. The first build should be high on the first and moderate on the second. Something central but genuinely difficult makes a poor opening project, because you learn the process on the hardest possible example, and something easy but peripheral proves nothing anyone will fund a second time.

Which tools give the biggest return?

The ones where a single owned system replaces several at once, because the same work was spread across all of them. In ecommerce that usually means operations: order handling, fulfilment and merchandising sitting in three tools and a spreadsheet, all wrapped around the platform you are keeping. The platform stays, the layer around it is what you own, and it can then talk directly to whatever else you run, from your ERP to an AI sales agent on the storefront.

How Do You Choose Who Builds It?

Start with judgment rather than capability. Anyone will happily hand you a shortlist of things they would enjoy rebuilding. A credible one tells you which subscriptions to carry on paying for, and why. If the keep-list comes back empty, you are talking to someone selling builds rather than someone advising you.

Then get these in writing, before anything starts:

• The three-year cost of staying, counting licences, integrations, admin time and the workarounds your team maintains
• The three-year cost of owning, counting the build itself, the hosting, the security work, and the maintenance you will want in years two and three
• A fixed quote, with what is out of scope and exactly what would cause the price to move
• The migration plan: how the data gets across, how long the two systems overlap, and what would trigger a rollback
• The handover: source in your own repository, a permissions and audit model, and a named owner afterwards, whether that is your employee, the builder, or someone else
• Confirmation that the code arrives unencumbered: no licence back to the builder, and no component you could not relicense or swap out later

The handover is the real test. Ask what you would need in order to keep running if you parted ways, and the answer should be a list of things you already hold rather than a reassurance.

Paperwork is necessary and not sufficient. Two things about the firm decide the rest. Whether they design systems or only write code, which shows up in whether they ask about your data model or about your screens. And whether they have built in your industry, or on the platform you are keeping, before. Domain knowledge is what stops a build from faithfully reproducing your workarounds instead of removing them.

What Does It Cost, and What Pays for It?

This is not new budget. You are moving money you already spend, from renting a workflow to owning one, which is why the audit above comes before any design work.

Compare it honestly and that means four numbers, not two. On the rented side, the three you just worked out. On the owned side, the build itself plus what it costs to run: hosting, and the maintenance budget for the years after launch. An owned system is cheaper to run than a per-seat subscription, not free to run, and any comparison that leaves the run cost out is one you should not trust.

After that, scope sets the price. Decide what you are not building before anything starts, and the quote can be fixed rather than estimated.

What Are the Steps for a SaaS Migration?

A controlled sequence, not a leap. Each step proves itself before the next begins, which is what keeps a replacement on its original quote and date.

• Audit every live subscription: cost, usage, integrations, the data inside it, and the contract terms, meaning renewal date, notice period, termination clause and data export rights. In Europe those rights are now partly statutory: the EU Data Act, Regulation (EU) 2023/2854, has applied to software-as-a-service providers since 12 September 2025 and requires export in a commonly used, machine-readable format
• Decide keep or replace in writing, with the reasoning for each
• Scope and fix the quote before any work starts
• Build in increments your team validates against real workflows
• Map permissions before anything moves, because who can see and do what is the part that silently breaks
• Run the new system in parallel with the old one, then in shadow mode against real data
• Agree the rollback: what triggers it, who calls it, and how long the old system stays available
• Move users across in groups, each group confirming before the next
• Keep the old system available through a stability period after the last group moves, with the contract end aimed at the far side of it rather than at the cutover
• Decommission once the new system has run clean through that period, and not before
• Hand over the source, the migrated data, the documentation and a named owner

This is the sequence we run on SaaS replacement projects, and the audit at the front of it is what lets us fix the quote before you commit to anything.

What Do You Actually Own at the End?

"Custom software" means very little on its own. Owning it has a checkable definition:

• The full source, in your repository, yours to modify or hand to anyone else
• Your data in a database you control, on infrastructure you choose
• A permissions model that says who can see and change what
• An audit trail of the activity that matters
• A named person responsible for keeping it healthy after handover

The test: could you walk away from whoever built it and keep running? If not, you bought a dependency rather than software.

Where Should You Start?

Not with a list of everything you could build. Take the largest renewal on your calendar in the next six months and answer three things: what it costs you a year, how much your team works around it, and what it would take to leave.

Sometimes that exercise ends with you renewing, and that is a useful outcome too, because now it is a decision rather than a default. Often enough it ends the other way: a tool you have been paying to work around for three years, a renewal date to aim at, and a budget that already exists because you are already spending it. That is the one worth owning, and it is usually the one you thought of first when you started reading.