When should you replace SaaS, and when should you leave it alone?

There is a bad version of "build your own". It starts with frustration, continues with scope creep and ends in an internal system that nobody wants to own. But there is also a bad version of SaaS. The question is not "SaaS or custom?". The question is: which layer are we talking about?

Two bad versions

Standard systems are often the right choice. ERP, payments, warehouse management, e-commerce platform and accounting are not areas where you should be creative for no reason. They are core systems. They should be stable, understandable and well supported.

But there is also a bad version of SaaS. It starts with a tool that solves 70 per cent of the problem. Then come the workarounds. Extra fields. Exports. Zapier flows. Consultants. Excel. Yet another SaaS on top of the first one. After a few years the company no longer has a system landscape. It has a compromise machine.

Three decisions

Keep standard systems when the process is generic. Payments, payroll, accounting, shipping labels, basic e-commerce engine, WMS and ERP are often poor candidates for replacement. They are full of edge cases, regulations, integrations and external requirements. Here it is better to choose strong standard systems and keep them clean.

Build around the system when the problem is cross-functional. Many valuable flows live between the systems. Product data needs to go from supplier to PIM to e-commerce to marketplaces. Wholesale sales need to see stock, margin, history and upcoming purchasing. Finance needs to understand order exceptions, returns, credit notes and VAT. No single SaaS owns the full picture. Here an operational layer is often the right path.

Replace SaaS when the tool has become more expensive than the problem. This happens when the company pays for features that are not used, lacks features that always need to be worked around, and still has to export data to make decisions. CRM, PIM, BI, project management and internal productivity tools are often candidates. Not always. But often.

Do not start with ideology

A good replacement case has three things: clearly recurring work, a clear data model and measurable value. If nobody can describe the flow, if the data is undefined or if the value is only "it feels better", it is too early to replace.

A good first step is instead to build a surface on top of existing systems. A command centre that reads data, shows context, suggests actions and writes back where it is safe. Then the team can experience the way of working before deciding what should actually be replaced.

This is also why lights-out.ai has three tiers. Entry proves the value. Standard replaces the SaaS layers where you already know that the standard tools no longer fit. Enterprise moves on to agents and flows that take over recurring work.

The mature question is not "can we build this ourselves?". With today's AI-assisted development, the answer is often yes.

The mature question is: should this be a standard system, an operational layer or owned software?

Once that question is answered, the rest becomes much simpler.