Multi-tenant analytics for fitness businesses — tenant #1: my own studios

The €100 Lakehouse — 1/12

Before choosing the architecture, I grep'd my saved job descriptions: Databricks ×7, Terraform ×7, Airflow ×4, dbt ×2. BI tools: ~0.

That grep set the founding rule, written down verbatim: "The dashboards layer is a product decision, not a CV decision." Career investment goes into Databricks, dbt and Airflow; Superset is install & configure. Refused: polishing the BI layer beyond what the product needs.

The product: a multi-tenant analytics platform for fitness-business management software. One pilot tenant today — my own two studios, the customer who never lies about requirements — designed for many: tenant_id is element [0] of every surrogate key, so a key without tenancy cannot even be written.

The pipeline: dlt → S3 → Databricks (bronze/silver/gold) → dbt → Postgres RLS → Superset · Airflow 3 on top.

The scoreboard, as of Aug 2026:
→ 43 bronze tables · 7,877 payments (@2026-08-02) · 1,850 people · 33 months of P&L
→ 4,277 Python + 892 dbt + 26 Playwright tests
→ €65–80/month against a €100 ceiling · Frankfurt, under GDPR
→ first commit to production dashboard with SSO: ~10 days

It also found €8,511 of genuinely lost revenue. More on that in week 9.

Lesson: over-invest deliberately on one axis — as long as the axis has a name and the decision is written down.

If you could deliberately over-invest in one axis of your next project, which one — and would you write the decision down?

Databricks · dbt · Airflow · Terraform · AWS

P.S. New tech post every Wednesday.

#100EuroLakehouse #DataEngineering #Databricks