When 130 SaaS tools become an architecture problem

SaaS made business software easier to adopt.

For a long time, that was mostly good news. Teams no longer had to wait months for central IT projects. Marketing could test campaign tools. Sales could extend a CRM. HR could automate onboarding. Operations could build a dashboard. Product teams could try workflows without first commissioning a full custom system.

But the same movement has created a different kind of complexity.

A post circulating on X today pointed at a striking pattern: German companies now run far more SaaS applications in parallel than they did only a few years ago. The exact number will vary from company to company. The underlying point is harder to dismiss: many organisations no longer have a single software problem. They have a software landscape problem.

One tool is rarely the issue.

The sum of the tools is the issue.

And the real risk often sits in the invisible connections between them.

SaaS sprawl rarely starts as a bad decision

Most fragmented software landscapes are not created because someone wanted chaos.

They are created for practical reasons:

A team needs a solution quickly.
An existing system is too rigid.
A supplier brings its own portal.
A customer requires a specific format.
A process needs improving without a large IT project.
An Excel workflow becomes too risky and needs replacing.
A new tool promises automation in two weeks instead of two quarters.

Each individual decision can be reasonable.

The problem appears later, when nobody owns the whole map anymore.

Customer data lives in the CRM, accounting system, support tool, newsletter platform and several project workspaces. Product data lives in the ERP, shop system, PIM exports and supplier portals. Approvals happen partly in Slack, partly by email and partly in a no-code automation that only one person understands.

The organisation keeps working.

But it is working on a fragile foundation.

The real pain lives between systems

Most SaaS tools are not bad in isolation. Many are well-designed, useful and commercially sensible.

The pain lives between them.

That is where the important questions sit:

Which system is the source of truth for customer data?
Who is allowed to change prices, roles or contract status?
What happens if an API is unavailable?
Which data may flow into which external system?
Which automations are critical for day-to-day operations?
Where are errors logged?
Who notices when a sync has silently failed for three days?
Which tools contain personal or confidential data?
Which integrations depend on private accounts belonging to individual employees?

These are architecture questions, even if they are not always called that.

That is why SaaS chaos cannot be solved through licence management alone.

A tool inventory is useful. But it does not explain how the company actually operates. What matters is the process and data architecture: where information is created, who uses it, which systems modify it and which dependencies emerge over time.

Shadow IT is often a symptom, not the enemy

The term shadow IT sounds like misconduct.

Sometimes it is. Unreviewed tools can create security risk, violate data protection rules or move critical company data into systems nobody controls.

But in many cases shadow IT is also a signal.

It says: a team had a real problem, and the official path was too slow, too expensive or too inflexible.

If companies respond only by banning tools, the need does not disappear. It moves elsewhere. People go back to spreadsheets, private accounts, manual workarounds and informal processes.

A better question is more practical:

What productive energy is hiding inside this shadow IT — and how can we make it safe, maintainable and scalable?

This matters especially for mid-sized German businesses. Many companies have grown processes, experienced specialist teams and limited IT capacity. They do not need enterprise bureaucracy. But they do need clear guardrails so that local improvements do not become long-term system debt.

Why AI makes the issue more urgent

AI tools accelerate this pattern.

Not only because new SaaS products include AI features. More importantly, teams can now build small internal applications, automations and integrations faster than before.

A department can use no-code tools, AI assistants or agents to create an internal portal in a short time. A developer can use AI support to build several integrations in days rather than weeks. A product team can test prototypes before the classic roadmap process has even started.

That is useful.

But it increases the need for architecture.

When implementation costs fall, more things get implemented. When more things are implemented, more interfaces appear. When more interfaces appear, data ownership, access control, monitoring and accountability become more important.

AI does not automatically create a good software landscape. It makes the existing landscape faster.

If the structure is sound, that is an advantage. If the structure is missing, the result is a more complex mesh of tools, scripts, workflows and half-documented assumptions.

What companies need first: an integration map

The first practical step is not a grand transformation programme.

It is an integration map.

Not a slide deck that dies in a folder, but a working overview that teams actually maintain. It should answer at least these questions:

Which SaaS tools are in use?
Which tools are critical for sales, operations, finance, product or customer support?
Which data objects move between them?
Which system is the source of truth for each object?
Which integrations are official and which are informal?
Which flows run via API, CSV, email, Zapier/Make, webhooks or manual exports?
Which accounts, tokens and permissions are used?
Where are monitoring, logs and error alerts configured?
Who is responsible from the business side and the technical side?

This map does not need to be perfect on day one.

It needs to be honest.

Within a few hours, patterns usually become visible: duplicate data entry, risky dependencies on individuals, undocumented automations, unnecessary tools, missing owners or critical processes without monitoring.

Three categories make the cleanup easier

Not every integration deserves the same amount of attention.

A useful split is:

1. Critical operational integrations

These are connections that affect revenue, delivery, support, billing or legal obligations.

Examples include CRM to ERP, shop to inventory, support tools to customer records, billing to accounting, identity management to internal systems.

These need robust architecture: clear data ownership, error handling, repeatability, access control, tests, documentation and rollback strategies.

2. Productivity integrations

These are workflows that make teams faster but do not immediately threaten operations if they fail.

Examples include notifications, internal dashboards, simple automations, reporting flows and handovers between project management tools.

Here, teams can be more pragmatic. But these integrations still need owners, visible failures and periodic review. Otherwise they quietly become critical later.

3. Experiments and prototypes

These are new tools, AI workflows or automations that are being tested deliberately.

Speed should be possible here. But experiments need boundaries: no production data without review, no permanent shadow process, a clear test period and a clear decision afterwards.

This distinction avoids two bad extremes: blocking everything or allowing everything.

API management is not only technical

When many systems talk to each other, API management sounds like a purely technical topic.

It is also governance.

Good API and integration management clarifies:

which interfaces are officially supported;
which data formats are stable;
how authentication and permissions work;
how changes are announced;
how errors are handled;
how systems are versioned;
which external vendors have access to company data;
which integrations matter for compliance.

This does not have to mean buying a large platform immediately. For many mid-sized companies, the starting point is a clean architecture decision: which systems are core systems, which are satellites, which data flows are allowed and which integrations belong in a controlled technical layer instead of individual tool accounts.

That layer may later become an internal API gateway, an integration platform, a small backend, an event-driven system or a combination of these. The label is less important than the principle: critical connections should not appear by accident.

When custom software is better than one more SaaS subscription

SaaS is often the right choice.

But not always.

Another tool makes sense when it solves a clearly bounded problem, holds little critical data and fits well into the existing landscape.

Custom software or an internal tool becomes attractive when:

several SaaS systems are being held together by manual work;
a core process does not fit cleanly into standard software;
teams maintain the same dataset across many tools;
compliance or data protection requires a controlled solution;
a workflow is strategically important and should not depend on a vendor roadmap;
the cost of licences and workarounds becomes higher than a focused build.

The point is not to build everything yourself.

The point is to decide consciously what should be bought, integrated and built.

At McDougall Digital, we like to look at these decisions through both an architecture lens and a product lens: Which software should remain standard? Where is a lean integration enough? Where does an internal product make sense because it reflects the operational core better than another SaaS block?

A pragmatic 30-day plan

For companies that feel SaaS sprawl but do not want to start a huge transformation project, a focused first month can create real clarity.

Week 1: Create visibility

Collect the most important tools, integrations, data flows and owners. You do not need every minor tool on day one. Start with sales, operations, finance, support and product-critical processes.

Week 2: Prioritise risk

Mark integrations involving production data, personal data, revenue, manual exports, private accounts, missing monitoring or unclear ownership.

Week 3: Define guardrails

Set simple rules: Who may introduce new tools? Which data may go where? Which integrations need review? Where are API tokens managed? Which automations must be documented?

Week 4: Fix the first three knots

Do not pick twenty problems. Pick three.

For example: replace a critical CSV sync, remove a private automation account, define the source of truth for one key dataset, stabilise an error-prone integration or build an internal dashboard that replaces several manual reports.

This creates trust. And trust is more important than a perfect architecture programme.

The goal is not less software. The goal is more control.

Modern companies are not going back to a single-system world. They should not.

SaaS remains valuable. AI-assisted tools will become more important. Departments will still need fast solutions. The question is not how to stop this development.

The question is how to make it manageable.

A good software landscape allows local speed without losing central control. It gives teams useful tools without scattering company data. It uses standard software without making core processes randomly dependent on vendor choices. It allows experiments without letting them silently become critical infrastructure.

That is architecture work.

Not architecture for its own sake, but architecture as the condition for sustainable digitalisation.

How McDougall Digital can help

If your SaaS landscape has grown to the point where nobody can confidently explain which tools, data flows and automations are truly critical, that is fixable.

McDougall Digital helps companies make software landscapes visible, maintainable and safer — from integration mapping and API/data architecture to the development of lean internal tools.

We are especially useful where technical decisions and product reality meet: Which systems should stay? Which interfaces need hardening? Which workflows deserve custom software? And where can AI-supported development safely accelerate delivery without creating new shadow IT?

The best time to bring order to SaaS chaos is not after the next outage.

It is while the organisation is still fast enough to turn control back into speed.