How we handle multi-tenant billing for EU agencies

Cadensa — Sun, 05 Jul 2026 19:46:42 +0000

The constraint: one product, multiple billing realities

Cadensa is a time tracking tool for EU agencies. Each agency is an organizational unit in the system — isolated MongoDB database, isolated workspace hierarchy, isolated team permissions. The multi-tenant architecture was straightforward to design because the isolation requirements were clear.

Billing isolation is less obvious. At the surface, it looks like a subscription management problem. Under that, it's a per-tenant rate card problem, a currency problem, a VAT calculation problem, and a payment method availability problem. Stripe's global defaults work fine if your customers are mostly US SaaS buyers. For EU agencies paying by SEPA direct debit or iDEAL, Mollie is the right tool. For the actual billing logic — rate cards per workspace, billable hour calculations per project, invoice generation per billing cycle — Mollie handles payment collection, not the data model.

What we built: per-workspace rate cards

The billing model works at two levels. At the unit level, a subscription defines the plan tier (Free / Pro / Enterprise) and the billing cycle. At the workspace level, rate cards define hourly rates per team member, per project type, or flat fee per engagement. These are what agencies actually use to calculate client invoices.

The rate card data lives in the unit's own MongoDB database, not in a shared billing service. That decision was deliberate. Under GDPR, the right to erasure applies to all data the controller holds. If rate card history lived in a shared billing database, deleting a unit would require coordinating across two systems. With the data in the unit's isolated database, deletion is a single operation: drop the database.

The Mollie integration handles the subscription layer only. Payment intents, webhooks, plan upgrades, subscription lifecycle — all of that goes through Mollie. The rate cards, billable hours, and generated invoice data stay inside the tenant.

What was hard: webhooks and tenant resolution

The hardest part wasn't the rate card model. It was figuring out which tenant a Mollie webhook belonged to.

Mollie sends webhook events to a single endpoint. The event contains a payment or subscription ID, not a tenant identifier. On the first attempt, we looked up the tenant by iterating over active subscriptions. That works at low scale. It doesn't work when there are enough tenants that the lookup becomes an O(n) database scan on every payment event.

The fix was non-obvious: when creating a subscription in Mollie, we pass the unit's bundle ID as metadata. The webhook handler reads that metadata first, resolves the correct tenant database, and processes the event inside that tenant's context. One lookup instead of a scan.

What we'd do differently

Build the tenant resolver before the billing integration, not after. The shape of the multi-tenant routing logic determines how every external service call gets structured. Getting that wrong early means refactoring webhook handlers, subscription creation flows, and invoice generation simultaneously — which is exactly what we did.

EU billing also requires accepting that there is no universal solution. Payment method availability, VAT rules, invoice formatting requirements, and currency expectations vary by member state in ways that no single billing library handles cleanly. The right model is a thin, tenant-aware billing service that delegates payment collection to a provider built for European markets, and keeps everything else in the tenant's own data layer.

Whether that's the right tradeoff for every multi-tenant SaaS is a separate question. For a GDPR-first product, it's the only tradeoff that actually works.

Building Cadensa — EU-native time tracking for agencies. cadensa.io

Why we built EU-native time tracking (and what Schrems II has to do with it)

Cadensa — Fri, 26 Jun 2026 06:12:23 +0000

In 2020, the Court of Justice of the European Union invalidated the EU–US Privacy Shield. The ruling — known as Schrems II — declared that US surveillance law makes it impossible for US companies to guarantee the privacy of EU citizens' data, even if that data is stored "in Europe."

Most SaaS founders in the US probably shrugged. Most EU agency owners probably didn't notice at all. But the implications were significant: transferring personal data to a US-based processor became legally risky, even if those processors had EU data centers.

I built Cadensa because I kept running into this exact problem while advising small EU agencies on their software stack.

The problem hiding in plain sight

Let's say you run a 12-person digital agency in Amsterdam. You use a popular US time tracking tool — one that has a "Frankfurt data center" checkbox. You tick the box, feel good about it, and move on.

Here's what you might not know:

The vendor is a US company subject to FISA Section 702 and CLOUD Act requests
Even if your data sits on EU servers, US authorities can compel access
Your DPA is using standard contractual clauses that post-Schrems II case law increasingly views as insufficient
Your enterprise clients — especially in finance, healthcare, or public sector — are starting to ask for a data processing agreement that names the actual sub-processors

None of this is FUD. It's just the current legal reality.

And the truly ironic part: time tracking data is surprisingly sensitive. It contains project names, client names, employee working hours, task descriptions, and billing rates. It's exactly the kind of data that triggers GDPR Article 5(1)(f) — integrity and confidentiality.

What we built instead

Cadensa runs entirely on Hetzner Cloud, Frankfurt. Not "Frankfurt as a region on AWS." Hetzner is a German company, incorporated in Germany, subject to German law and the GDPR — not the CLOUD Act.

GDPR compliance isn't a toggle you flip on the Enterprise plan. It's on every plan, including Free:

Data stored in the EU (Germany)
Right to erasure: full account deletion with 7-day reversible grace period
Right to portability: JSON export of all your data, on demand
Data processing agreement available at signup, not behind a sales call

Multi-tenancy is database-level, not row-level. Each organizational unit gets its own isolated MongoDB database. A breach in one tenant can't cascade to another. This is more expensive to operate, but the security and compliance story is clean.

The technical part (for the devs reading this)

The stack: Express.js + TypeScript on the backend, React 18 + Vite on the frontend, MongoDB (multi-database architecture), Socket.io for real-time presence and live updates.

The thing that surprised me most architecturally: implementing GDPR rights as first-class API citizens is genuinely hard. "Delete my account" sounds simple. In practice, it means:

Soft-delete with a 7-day grace period (user can reverse)
Hard-delete: cascade across multiple databases (global user record + all tenant databases)
Anonymize data that legally must be retained (financial records, audit logs) rather than delete it
Export: traverse the entire data graph and serialize it to a portable format

We have a gdprRights.service.ts that handles this. It's one of the more complex parts of the codebase, and it's not optional — it's a legal requirement.

Email hashing was another non-obvious decision: user emails in the global database are stored as SHA-256 hashes. We never store plaintext emails globally. This limits some email-based lookups, but it means a global DB dump leaks no PII.

What I'd tell other EU founders

If you're building a SaaS for European SMBs or agencies, EU data residency is becoming a selling point, not just a checkbox. We've had prospects come to us specifically because their enterprise clients required it.

You don't need to be perfect on day one. But you do need:

A clear answer to "where is my data?"
A DPA you can actually show to a client's legal team
No hand-waving about "we're GDPR compliant" without specifics

The 12-person agency in Amsterdam doesn't have a dedicated compliance officer. They need a tool that makes the right answer easy to give.

That's what we're building with Cadensa.

Cadensa is EU-native time tracking for agencies — free plan, no credit card required. If you're building something similar or have thoughts on GDPR + SaaS, I'd love to hear from you in the comments.

cadensa.io — building in public, one sprint at a time.

DEV Community: Cadensa