· 6 min read

What a 15-Tool SaaS Stack Reveals About US Dependency

We mapped the full SaaS stack of a typical 25-person European professional services firm. Fifteen tools, twelve US-controlled, and a dependency structure that nobody had documented. Here is what we found.

SaaS Dependency Mapping Case Study

Take a typical European professional services firm. Twenty-five employees, two offices, founded six years ago. They chose their tools the way most companies do: whatever worked at the time, whatever the first hire already knew, whatever had a free tier that scaled with them.

Nobody sat down and decided to build the company on American infrastructure. It happened one tool at a time.

We mapped their full stack. Fifteen core tools. Here is what the dependency structure actually looks like.

The Stack

# Tool Function Vendor HQ Data Location
1 Google Workspace Email, calendar, files, identity US EU (configured)
2 Slack Internal communication US (Salesforce) US
3 Notion Documentation, wiki, project notes US US
4 Salesforce CRM US EU (configured)
5 HubSpot Marketing automation US US
6 Stripe Payment processing US EU/US
7 GitHub Source code, CI/CD US (Microsoft) US
8 Figma Design US US
9 Calendly Scheduling US US
10 Zoom Video conferencing US US/EU
11 1Password Password management Canada Canada/US
12 Cloudflare DNS, CDN US Global
13 Vercel Website hosting US Global
14 Xero Accounting New Zealand/UK UK
15 Personio HR and payroll Germany EU

Twelve of fifteen tools are US-headquartered. Two (Xero, Personio) are non-US. One (1Password) is Canadian, which shares intelligence agreements with the US under Five Eyes.

On the surface, this looks like a problem you could solve by swapping a few tools. The reality is more complicated.

The Dependency Graph

The tools do not exist in isolation. They connect to each other, and those connections create a structure that is harder to change than any individual tool.

Google Workspace sits at the centre. It is the identity provider. Every employee logs into Slack, Notion, Salesforce, HubSpot, GitHub, Figma, Calendly, and Zoom using their Google account. That is nine SSO connections flowing through a single US-controlled identity layer.

Slack is the nervous system. It receives notifications from Salesforce (new deals), GitHub (pull requests), HubSpot (form submissions), Calendly (new bookings), and Google Calendar (meeting reminders). Replacing Slack means rewiring all five integration channels.

Salesforce and HubSpot share data bidirectionally. Leads flow from HubSpot to Salesforce. Customer data flows back. Both depend on Google SSO for employee access. The data relationship between them means you cannot migrate one without considering the other.

Stripe connects to Salesforce, Xero, and HubSpot. Payment events in Stripe trigger revenue updates in Salesforce, invoice creation in Xero, and deal-stage changes in HubSpot. Three integration paths that all pass through a US payment processor.

GitHub connects to Slack and Vercel. Code pushes to GitHub trigger deployment on Vercel and notifications in Slack. The development workflow depends on two US platforms operating in sequence.

What This Structure Means

The dependency graph reveals three things that a simple vendor list does not:

1. Single points of failure are hidden in the identity layer

If Google Workspace becomes unavailable, this organisation loses access to 9 of its 15 tools within minutes. Not because those tools are broken, but because the login mechanism is broken. Salesforce still works. Slack still works. But nobody can get in.

This is the most common structural risk we see in European organisations. The identity provider is almost always US-controlled (Google or Microsoft), and it fans out to everything else.

2. Integration coupling creates cascading migration costs

Replacing Slack seems simple: pick Element or Rocket.Chat, move the channels, tell people to switch. But Slack receives automated messages from five other tools. Each integration must be rebuilt on the new platform. Some integrations (Salesforce notifications, GitHub webhooks) are straightforward. Others (HubSpot workflow triggers with conditional formatting in Slack) are custom and undocumented.

The same applies to every tool in the stack. The cost of replacing one tool includes the cost of rebuilding every integration that touches it.

3. US jurisdiction concentrates through ownership, not just geography

Several tools in this stack have configured EU data residency. Google Workspace stores data in the Netherlands. Salesforce uses an EU data centre. But the legal entity that controls the infrastructure, the encryption keys, and the administrative access is still US-headquartered. EU data residency addresses one concern (physical location of bytes). It does not address jurisdictional control.

The CLOUD Act applies to Google, Salesforce, Slack, HubSpot, Stripe, GitHub, Figma, Zoom, Cloudflare, Vercel, and Calendly. Twelve of fifteen tools. Moving data to EU servers does not change this.

Scoring the Stack

We scored each tool on two dimensions: sovereignty exposure (how much jurisdictional risk it creates) and replaceability (how hard it is to switch).

Tool Sovereignty Exposure Replaceability Combined Risk
Google Workspace Very High (identity hub) Hard Critical
Slack High Medium High
Notion Medium (internal docs, no client data) Medium Medium
Salesforce High (client data, revenue data) Hard High
HubSpot Medium-High Medium Medium-High
Stripe High (financial transactions) Medium High
GitHub Medium (source code, IP) Easy-Medium Medium
Figma Low-Medium (design files, no PII) Medium Low-Medium
Calendly Low (scheduling metadata) Easy Low
Zoom Medium Easy Low-Medium
1Password Medium (credential vault) Medium Medium
Cloudflare Medium (DNS, availability) Easy Low
Vercel Low-Medium (static hosting) Easy Low
Xero Low (UK jurisdiction) Medium Low
Personio Low (EU jurisdiction) Medium Low

Three tools scored “Critical” or “High” risk with hard replaceability: Google Workspace, Salesforce, and Slack. These are the structural dependencies. Everything else is either lower risk or easier to replace.

What a Realistic Response Looks Like

This organisation does not need to replace all fifteen tools. It needs to address the structural dependencies that concentrate the most risk.

Phase 1: Quick wins (weeks, minimal cost)

  • Move DNS from Cloudflare to Hetzner DNS or deSEC. Zero downtime. Reduces one US dependency.
  • Move website hosting from Vercel to a European provider (Hetzner, Uberspace). Static site migration is straightforward.
  • Replace Calendly with Cal.com (open source, self-hostable). Feature parity for basic scheduling.

Phase 2: Strategic diversification (months, moderate cost)

  • Deploy Keycloak alongside Google Workspace as a parallel identity provider. Connect the three most critical applications (Salesforce, Slack, GitHub) to both. This creates identity redundancy without requiring a full Google migration.
  • Back up Google Drive and Gmail to EU-hosted storage. Independent copy of all data, accessible if Google access is revoked.
  • Replace Zoom with a European alternative (Jitsi, BigBlueButton for internal meetings; keep Zoom for external calls if needed).

Phase 3: Deep restructuring (quarters, significant investment)

  • Migrate email from Gmail to Proton Mail for Business. The highest-value single migration for sovereignty.
  • Evaluate Salesforce alternatives or implement data mirroring to EU-hosted systems.
  • Migrate from Slack to Element (Matrix). Rebuild integrations on the new platform.

Phase 4: Identity independence (the long game)

  • Complete migration from Google identity to Keycloak/Authentik. Disconnect all applications from Google SSO. This is the hardest step and the most impactful.

Total estimated cost for Phases 1 through 3: €15,000 to €35,000 in migration labour, plus ongoing infrastructure costs of approximately €300 to €600/month. Phase 4 adds €10,000 to €25,000 depending on the number of SSO connections.

The Lesson

This firm did not choose US dependency. It accumulated it. Each tool was a reasonable decision at the time. The aggregate result is a stack where twelve of fifteen tools are controlled by US companies, where the identity layer is a single point of failure, and where cascading integrations make changing any one tool a multi-tool project.

The point of mapping the stack is not to trigger alarm. It is to make the dependency visible, so that decisions about what to change (and what to keep) are deliberate rather than accidental.


Sovereign Shift maps your full stack, scores every dependency, and delivers a phased action plan like the one above. Start with a dependency audit →