We Reviewed 134 European Alternatives, and Our Own Site Fails the Test

We Reviewed 134 European Alternatives, and Our Own Site Fails the Test

We built a tool that turns digital dependency into a number: twelve questions, a score per layer, a migration plan. It lives at sovereignty.balane.tech and costs nothing.

The most useful finding appeared when we pointed it at ourselves. The site that explains why the jurisdiction of your provider matters is served by a company in the United States. In our own directory, we would be on the wrong side of that line.

This article is less about the tool than about what became visible while building it. Reviewing 134 products one by one, asking of each which law its parent company answers to, teaches three things that appear in no vendor brochure. One of them is about us.

The mistake that derails most conversations

In almost every conversation about sovereignty, one sentence arrives early: "our data is in Frankfurt." It is usually true and usually beside the point.

The US CLOUD Act of 2018 obliges US companies to produce data they own, hold or control, wherever in the world that data physically sits. The order is served on the company, not on the building. A server in Frankfurt, operated by the German subsidiary of an American group, does not change what the parent is compelled to do. The question is not where the disk is. The question is who has to comply with a court order.

From that follows the single grading rule behind the directory. It is an uncomfortable one, because it renders most marketing claims worthless:

The rule cuts in both directions, and the second one surprised us more than the first. It disqualifies products marketed as European. It also admits products that look American at first glance, because with open-source software you run yourself, the vendor is not in a position to hand over data it never receives.

What reviewing 134 products teaches you

The directory was conceived as a list of European replacements. Reviewing turned it into something else: a list with footnotes. The footnotes are the actual value.

That a directory of European alternatives contains 27 entries whose parent company sits outside the EU is not an oversight. It is the most interesting part of it. Three patterns kept recurring.

One: the product is European, the owner no longer is. ownCloud is widely regarded as the German answer to Dropbox. ownCloud GmbH has belonged to the US company Kiteworks since 2023. The code stays open and self-hostable. The vendor, however, answers to US law. Anyone who made a sovereignty decision in 2022 has not had one since. Changes of ownership are the most common way a carefully researched decision quietly expires, and nothing notifies you when it happens.

Two: the operating model decides, not the product. Jitsi Meet is free software owned by the US provider 8x8. Use meet.jit.si and you are using a US service. Run the same software on your own server and 8x8 is not part of the picture. The same pattern holds for Matomo, whose company sits in New Zealand, for Grafana, which is now a US company, and for Keycloak, which is carried by Red Hat and therefore by IBM. For all four, the honest answer to the sovereignty question is it depends where it runs. A directory that only knows "European: yes/no" cannot express that, which is why ours records the hosting model separately.

Three: provenance is rarely where you would look for it. The commercial entity behind Gitea, Gitea Ltd., is registered in Hong Kong. That is the reason the Forgejo fork happened in 2022. It does not say so on the product page. You find it in a company register, on a mailing list, in a blog post written by the people who forked it. It is material to a purchasing decision and invisible to a search engine.

So every entry carries a field we call the catch: the thing the vendor would not put on its own front page. Including for products we like and use. A directory without that field is a brochure with a filter bar.

Why the bottom of the stack beats the top

The second lesson concerns order. Dependency is not a list, it is a stack. Each layer rests on the one beneath it and inherits its jurisdiction, whether or not anyone intended that.

A European CRM running on an American cloud is not a European CRM. It is a European application on an American foundation. This is not pedantry: when the lower layer fails, gets suspended, or has to comply with an order, the provenance of the upper one helps nobody.

The right-hand column below is the one worth reading. It does not state how dependent a layer is; it states what changing it costs.

The practical consequence runs against the order in which these things are usually tackled. The loudest debate is about the top layer: which model, which assistant. That layer is also the cheapest to change: an interface, a configuration, an afternoon. The layer with the most leverage is sign-in. Move your identity provider and you move control over access to everything above it, which is exactly why it takes months and why nobody volunteers to start there.

One change at the bottom usually pays more than three at the top. That is the most unwelcome sentence the tool produces, because it puts the effort where it hurts.

Our own case: this site runs on a US provider

Which brings us back to us.

sovereignty.balane.tech is served by Vercel, a company based in the United States. Its operator is therefore subject to the same CLOUD Act the site explains. There is a data processing agreement under Art. 28 GDPR, and the transfer relies on the adequacy decision for the EU-US Data Privacy Framework. That is the legally clean formulation. It does not change the grade our own directory would give.

We could have left this out. Nothing about a static site announces where it is served from. We write it down because a site about dependency that conceals its own is an advertisement.

An honest account includes the other side of the ledger, and here it is favourable. What is served is public content and nothing else: no accounts, no forms, no database, no cookies, no analytics. Answers given in the sovereignty check never leave the browser: they sit in local storage, are evaluated there, and reach no server, ours included. What does arise at the host is connection logs containing IP addresses. The exposure is small. It is not zero.

None of this is self-deprecation as a rhetorical move. It is the ordinary case. Almost nobody chooses their stack on a greenfield; most dependencies accumulated over years, each one defensible at the time it was taken on. Turning that into an accusation helps no one. Turning it into a sequence does.

It is also worth being explicit, because the topic invites caricature: this is not an argument that European software is better, nor that American providers are untrustworthy. It is an argument about where decision rights sit when something goes wrong. If the concentrated positions were European and the dependent customers American, the engineering critique would read identically.

What you can find out in five minutes

The reason this became a tool rather than another article: the general picture is by now well understood. What is missing is the translation to a specific company.

The sovereignty check asks twelve questions about what you use daily: cloud, sign-in, email, files, video, business applications, AI, keys and contracts. Out comes a score per layer, your three biggest levers, and a roadmap ordered by impact divided by effort, across four horizons: what you can do this week, what takes six months, what takes twelve, and what only moves with the next contract cycle.

Three things deliberately do not happen. There is no sign-up. No data is transmitted to us. And nothing is sold to you: we earn nothing on any of the 134 alternatives listed and are paid for none of the entries.

The roadmap is built to print, because in practice it ends up as an appendix in a board meeting. That is the moment the tool was designed for: not the realisation that you are dependent, but the document someone can use to justify a decision.

What this has to do with architecture

We build software for mid-sized companies, and our position on the sovereignty question is unexcited: good architecture is sovereign architecture. Portability, open formats, interchangeable components and a documented way out are not political requirements but craft ones. Meet them and independence arrives as a by-product, and it pays even if the geopolitical risk never materialises, because the same properties change every price negotiation you will ever have.

Which is why the most important question in any software decision is not "what can it do?" but "how do I get back out?" A company that can answer it does not have to leave. It merely can.

The tool is at sovereignty.balane.tech. The directory was last reviewed in full in August 2026. If you spot an error, or a change of ownership we have missed, tell us. Corrections are the only reason a list like this stays useful over years.