When does it make sense to leave SaaS and build your own?

“Build versus buy” is the wrong framing, because it implies a single decision made once for the whole company. In practice the question is per capability, revisited as you grow, and the honest answer is usually “buy most of it, build the two things that matter”.

This guide is about recognising which two, and about leaving well when you decide to.

The signals that mean the fit has broken

None of these on their own is decisive. Three or more together usually is.

The export button is load-bearing. Someone exports from the tool every week and does the real work in a spreadsheet. That spreadsheet is the actual system; the subscription is an expensive data entry form.

Seats are rationed. People who would benefit from access do not have it because licences cost money. Warehouse staff, field engineers, dealers, temporary workers. When a pricing model changes who is allowed to see information, it has started running your organisation.

The workarounds have names. Every company has a couple. When they have nicknames, documented procedures and dedicated owners, the tool is no longer a tool.

A process change requires a vendor. You want to add an approval step, and the answer is a feature request, a professional services quote, or “you could use a custom field for that”. Speed of change is a competitive variable and you have outsourced it.

Renewal is now a negotiation you dread. Published 2026 data shows 79% of IT leaders faced price increases at renewal over the previous twelve months, with typical rises of 8–12% and aggressive vendors at 15–25%, plus AI-premium tiers commanding a further 25–35%. If your renewal conversation is now an annual budget event rather than an administrative one, the economics have changed underneath you.

You are paying for a suite and using a quarter of it. Common, and rarely reconsidered once the purchase decision is old.

Where SaaS is genuinely the right answer

It is worth being fair to the other side, because the failure mode of this decision is building things you should have bought.

Buy, and keep buying, where:

• The function is a commodity you have no reason to differentiate on: accounting, payroll, email, video calls, password management.
• The function carries compliance certifications you would otherwise have to obtain and maintain.
• The function has strong network effects — it is valuable because other companies use it too.
• Change is infrequent and the vendor’s conventions are fine.
• Your seat count is small and unlikely to grow much.

Build where the process is genuinely yours, changes often, and touches enough people that per-seat pricing becomes structural. Everything else is a judgement call.

The five-year comparison, done honestly

Most build-versus-buy spreadsheets are wrong in the same two ways: they use today’s subscription price for all five years, and they omit the buyer’s own internal effort on both sides. Fix both and the comparison becomes useful.

Line	Stay on SaaS	Build custom
Year 1	Subscription + implementation + configuration	Build cost
Years 2–5	Subscription, escalating at each renewal	Optional maintenance, 12–25% of build value
Adding 20 users	Linear increase, every year thereafter	$0
Adding a workflow the vendor supports	Possibly a higher tier	Build increment
Adding a workflow the vendor does not support	Spreadsheet, indefinitely	Build increment
Integration to your other systems	Connector fees or middleware	Built once, owned
Hosting	Included	Paid directly to your cloud provider
Your internal time	Configuration, workarounds, exports	Discovery, testing, training
Asset at year 5	None	Source code, schema, data

Two rules for running it. Escalate the subscription column at a realistic renewal rate rather than holding it flat. And use your realistic year-five seat count, including the people currently excluded because seats are expensive — otherwise you are comparing a growing cost to a fixed one while pretending it does not grow.

Our published bands for the build column are $3,000–6,000 for a single focused module over 2–4 weeks, $8,000–15,000 for a multi-department system over 4–8 weeks, and $20,000+ for an end-to-end platform over 3–6 months, with optional maintenance at 12–25%. The full table is on the pricing page, and there is an interactive comparison on SaaS to custom.

What you actually give up

Be clear-eyed about this, because it is the part vendors of custom software tend to skip.

• The roadmap. Someone else was improving the product for free. Now improvements are your budget line.
• Certifications. If the tool holds attestations that satisfy your customers’ procurement, you inherit that requirement.
• A support desk that is not you. With custom software, first-line support is internal unless you contract otherwise.
• Encoded convention. A mature product embodies a lot of accumulated knowledge about how this kind of work is done. Building custom means you are responsible for that knowledge.

For commodity functions, those four are exactly what you are buying and they are worth the money. For your differentiating processes, they are the constraint.

A staged exit that does not risk the business

Never replace a live system in one move. This sequence keeps the maximum loss small at every stage.

1. Export everything first, while the relationship is good. Full data with keys, attachments, and the configuration that encodes your workflows. Verify with row counts and spot checks. Do this before you give notice, and before the vendor knows you are leaving.
2. Write down the actual workflow, not the one in the vendor’s documentation. Watch people work. The workarounds are requirements.
3. Pick the single most painful part and build only that. Four to six weeks, fixed price, in production alongside the subscription. You are buying evidence about the supplier as much as software.
4. Connect the two. The new module reads from and writes to the SaaS tool while both run. This proves the integration and removes the cutover cliff.
5. Move users in groups, not all at once. One team, then a second, with a week between.
6. Run parallel for one full cycle. A complete month, reconciled. Tedious, and the cheapest insurance available.
7. Only then reduce seats. Most subscriptions bill annually; time the reduction to the renewal date or you will pay for capacity you stopped using.
8. Keep read-only access for the statutory retention period. Confirm before cancellation that you can retrieve historical records without the licence.

Three situations, three different right answers

“Our CRM costs $2,400 a month for 30 seats and we use maybe a fifth of it.” Before building anything, try a cheaper tool in the same category. A build only makes sense here if your sales process is genuinely unusual, and most are not. This is a procurement problem wearing a software problem’s clothes.

“Our field service tool cannot handle our scheduling rules, so dispatchers plan in a spreadsheet and copy it in.” Build. The spreadsheet is the requirement document and it already exists. This is precisely the case where a package’s conventions are the constraint rather than the value, and a focused module — 2–4 weeks on our published bands — usually replaces the spreadsheet entirely.

“We are on three subscriptions that do not talk to each other, and someone reconciles them daily.” Build the integration, not a replacement. The tools may each be fine. The reconciliation job is the cost, and it is much cheaper to remove than the tools are to replace. Our approach to this is on the integrations page.

The pattern across all three: identify the specific cost you are actually paying, then choose the smallest intervention that removes it. “Replace the system” is rarely the smallest intervention, and it is almost always the first one proposed.

Negotiating a renewal while you decide

You will usually be inside a renewal window during this evaluation, and having a credible alternative changes that conversation materially.

• Know your real usage. Seats provisioned versus seats active in the last 90 days. Most companies are paying for 15–30% more seats than they use, and reclaiming those is free money regardless of what you decide.
• Ask for a multi-year price lock rather than a discount. Given published renewal escalation of 8–12% annually and up to 25% from aggressive vendors, a flat three-year price is often worth more than a one-year discount.
• Get the export terms in writing before you sign, not when you leave. Format, completeness, attachments, and how long access persists after termination.
• Do not disclose the build evaluation. It changes the vendor’s behaviour, and rarely in a way that helps you.
• Never let a renewal date force a build decision. Renew for a year while you run a proper pilot. A rushed replacement costs more than twelve months of subscription.

The mistakes that make this go badly

Rebuilding the SaaS tool feature for feature. You are not competing with a product company. You are replacing the twenty per cent you use with something that fits exactly. Copying the other eighty per cent is how a six-week module becomes a six-month project.

Starting with the biggest system. Start with the most painful workflow, which is usually not the biggest system.

Not owning the code. If you leave a subscription for a custom build you do not own, you have changed vendors and worsened your economics. The repository must be in your account from the first commit, with the schema, deployment recipe and documentation as contracted deliverables. Detail in code ownership and lock-in.

Cancelling before the replacement is proven. Obvious, and it still happens, usually because a renewal date arrives at an awkward moment.

Ignoring the people side. Panorama Consulting’s research consistently names change management among the leading causes of system project failure. The software being better is not sufficient; people have to be brought through the change deliberately.

Further reading: package vs custom covers the trade-off in general terms, who we build for describes the situations we typically see, the delivery bands are on the pricing page, and a first module can be scoped through the quote form.

Frequently asked questions

How do I know if we have genuinely outgrown a SaaS tool?

Count the spreadsheets that exist beside it, count the workflows that stop because the tool cannot express them, and count how many people are excluded from it because seats are expensive. Two or three of each is normal friction. Ten is a diagnosis. The number of exports per week is the single best proxy.

Is custom software really cheaper over five years?

It depends on seat count and renewal escalation, and you should calculate it rather than assume it. Published 2026 data puts average annual SaaS increases at 8–12%, with some vendors at 15–25%, so a model that uses today's price understates the subscription side. Run both columns over 60 months with your own numbers.

What do we lose by leaving a SaaS product?

Four real things: the vendor's roadmap, their compliance certifications, their support desk, and the industry conventions baked into the product. For commodity functions those are worth paying for. For processes that differentiate you, they are what is holding you back. Be honest about which category the tool falls into.

Can we replace part of a SaaS tool rather than all of it?

Yes, and it is usually the right first move. Keep the subscription for the part it does well and build custom for the part it does badly, connected by an interface. You reduce pain quickly, learn how your supplier actually works, and keep the option to go further or stop.

How long does a replacement take?

On our published bands, a single focused module goes live in 2–4 weeks with a clickable prototype inside the first two weeks. A multi-department system runs 4–8 weeks. Replacing everything at once is possible and is almost always the wrong shape for a first project.

What happens to our data when we leave?

Export it before you give notice, not after. Full data with keys, attachments, and the configuration that defines your workflows. Verify the export against the live system with row counts and spot checks. Then keep read-only access for as long as your retention obligations require.

Related guides

• ERP data migration: the checklist that prevents a failed go-live
• Migrating off SAP Business One: the options, the order, and what to extract first
• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems

Service page: Migration guide