What makes a service European by Default

Ownership and control

A service qualifies if its parent company is registered and headquartered inside the EU, the EEA, Switzerland, or the UK, and a majority of shareholders and board control sits with European individuals or entities.

Wholly-owned subsidiaries of non-European parents don't qualify, even if a local European office exists. If the final beneficial owner is a non-European holding company, data and roadmap decisions ultimately flow there, which defeats the purpose of the directory.

Criteria:

• HQ in one of the qualifying European countries listed below
• Majority European ownership (no non-European parent)
• Founders or leadership primarily based in Europe

Qualifying countries

Albania , Andorra , Austria , Belgium , Bulgaria , Croatia , Cyprus , Czechia , Denmark , Estonia , Finland , France , Germany , Gibraltar , Greece , Hungary , Iceland , Ireland , Italy , Latvia , Liechtenstein , Lithuania , Luxembourg , Malta , Moldova , Monaco , Montenegro , Norway , Poland , Portugal , Romania , Serbia , Slovakia , Slovenia , Spain , Sweden , Switzerland , The Netherlands , Ukraine , United Kingdom

Data hosting and residency

Any personally identifiable information must live on infrastructure physically located in Europe and run by a European-owned provider. An AWS, GCP, or Azure region inside Europe does not count, because those providers remain subject to US law regardless of where the servers sit.

Hyperscalers can still play a supporting role for things like CDN edges, transient caches, or integrations where the data already lives elsewhere. They just can't be the system of record for user data.

Criteria:

• Primary data store is European-owned and hosted in Europe
• Backups and replicas stay on European infrastructure
• No personally identifiable data on US hyperscalers, even in European regions
• Hyperscaler use limited to non-identifiable, supporting workloads

Privacy and tracking

Our main focus here is on the actual user data a service collects, stores, and processes. It should be the minimum needed to operate, clearly explained, and handled under a real privacy policy rather than boilerplate.

We're more relaxed about ad networks. US-based options like AdSense are fine if a service relies on them, because there are few credible European alternatives today. What we do push back on is US-based product analytics and behavioural trackers when a European option exists.

Criteria:

• Collects only the user data needed to operate
• GDPR-compliant by design, not as an afterthought
• European-based product analytics preferred over US trackers
• Data Processing Agreement (DPA) available for B2B listings
• Clear data retention and deletion commitments

Policy transparency

We don't have opinions on whether a service should publish pricing, open-source its code, or expose its architecture. That's a business decision, not an ethics one. What we do care about is that the policies governing user data, such as privacy, terms, data processing, security, are public, readable, and actually describe how the product behaves.

Criteria:

• Publicly accessible privacy policy and terms of service
• Stated policies match real product behaviour
• Honest, non-deceptive product descriptions

Quality and maturity

Every listing has to be a product you could actually use in production. No side projects, landing pages, or abandoned GitHub repos.

Criteria:

• Actively developed (shipped updates in the last 12 months)
• Publicly accessible, so anyone can sign up or download
• Reachable support (email, chat, or community channel)
• No serious unresolved security or compliance issues