Digital Emigration

Why I’m reducing my dependence on US tech

Published:

This blog documents a personal attempt to reduce dependence on US‑based technology and rebuild a more resilient, sovereign digital life.

It also serves a second purpose: to explain why I am doing this publicly.

For years, my digital stack was almost entirely US based. That felt good. Convenient. Invisible. It was simply how things worked.

Until it wasn’t.

The trigger was Greenland.

Not Greenland itself, but what it symbolised: a United States that is becoming more unpredictable, more transactional, and more willing to use economic and technological power as leverage. That moment forced me to look differently at something I had taken for granted for decades: the infrastructure my digital life depends on.

What I mean by digital sovereignty

By digital sovereignty, I don’t mean autarky, nationalism, or rejecting American technology as such.

I mean something simpler and more concrete: understanding who ultimately controls the systems you rely on, under which jurisdiction they operate, and what happens when political, legal, or economic assumptions change.

In practice, that comes down to questions like:

These questions rarely matter until suddenly they do.

How locked-in I actually was

Looking honestly at my setup was uncomfortable. Like many people working in tech, I had optimised relentlessly for convenience and integration.

Email, documents, identity, backups, devices, authentication, publishing. All deeply interconnected. All largely subject to US jurisdiction.

Individually, none of these choices felt risky. Collectively, they formed a single point of failure.

Once you start mapping dependencies, you realise how difficult it is to change one layer without touching several others. I later turned this realisation into a dependency map of my personal tech stack, to make digital lock-in visible rather than abstract.

None of this felt risky for years. It felt convenient. Invisible.

Seen through the lens of jurisdiction, sanctions, policy shifts, or simple unreliability, it looks less like convenience and more like single‑point‑of‑failure design.

One practical consequence of this thinking is that even this site is intentionally designed to avoid platform dependency, which I describe in building this blog without a platform.

Why I’m documenting this publicly

Documenting this publicly is not accidental. It is a quiet form of protest.

For years, I was comfortable relying on a single jurisdiction. I assumed that international law, constitutional limits, and institutional norms would hold. That assumption no longer does.

What changed was not my tolerance for dependency, but my confidence that legal and political guardrails would be respected when it mattered. Once those guardrails become optional, dependency turns from convenience into exposure.

This is also a claim about freedoms that are easy to overlook in digital systems: freedom from coercion, freedom from opaque algorithms, and freedom from closed code and intellectual property walls that prevent inspection, exit, or competition.

By writing this in public, I’m making dependencies visible. First to myself, and then to others who may feel a similar unease but haven’t yet articulated it.

If enough individuals and organisations start treating technology choices as structural decisions rather than purely technical ones, the market will eventually respond, whether vendors like it or not.

The challenge ahead

This blog documents an attempt to reduce dependency on US platforms where reasonable alternatives exist, especially European or open systems governed by different legal and political assumptions.

Some transitions will be easy. Others will be painful. Some may fail entirely.

Everything is connected. I’m learning that the hard way.

What to expect

I intend to write roughly weekly about this journey:

Occasionally, I’ll also write about woodworking and 3D printing. Making physical things, understanding materials, and building objects you can actually hold feels like a useful counterweight to abstract digital dependency.

Final note

This blog is an attempt to think clearly, in public, about technological dependency and what it takes to unwind it responsibly.

It’s about building resilience, preserving room to manoeuvre, and not assuming that yesterday’s stability will automatically exist tomorrow.

What comes next is practical: mapping dependencies, testing alternatives, documenting failures, and sharing what holds up under real use.

If nothing else, this is a way to regain a bit of agency by making choices visible.

Let’s see where it goes.