Ich wusste, was Agenturen brauchten – also habe ich Multi-Tenancy am Tag 2 gebaut

21. August 2025. Tag 2 des Aufbaus von STRAŦUM.

Ich saß an meinem Schreibtisch mit einem funktionierenden KI-Agenten (Business Strategy), grundlegender Authentifizierung und einem sehr einfachen Datenmodell. Kaffee wird kalt. Ich wusste genau, für wen ich bauen wollte: KMUs, die KI-Marketing-Hilfe brauchten, UND Agenturen, die es bei mehreren Kunden einsetzen konnten.

Beide Zielgruppen. Von Tag 1 an.

Nach 20 Jahren auf der Agenturseite verstand ich, was Agenturen tatsächlich brauchen – nicht die glänzende Marketing-Version, sondern die chaotische Realität der Verwaltung von 10-15 Kunden mit unterschiedlichen Strategien, unterschiedlichen Brand Guidelines, unterschiedlichem alles. Ich wusste auch, dass KMUs dringend erschwingliche strategische Hilfe brauchten.

Aber an Tag 2, als ich auf mein einfaches Datenmodell starrte, erkannte ich etwas Unangenehmes: für beide Zielgruppen zu bauen bedeutete, Multi-Tenant-Architektur zu bauen. Jetzt. Nicht später.

Am Ende des Tages hatte ich mich für eine Entscheidung verpflichtet, die meine Entwicklungskomplexität verdreifachen und meinen Zeitplan um Wochen verlängern würde.

Ich habe Multi-Tenant-Architektur ab Tag 2 gebaut.

War das ehrgeizig oder wahnsinnig? Ehrlich gesagt, ich war mir nicht sicher. Ich bin mir immer noch nicht zu 100% sicher. Aber hier ist die Geschichte, warum diese Entscheidung – getroffen mit fast keinem funktionierenden Produkt – sich als eine der wichtigsten technischen Entscheidungen herausstellte, die ich getroffen habe.

Warum beide Zielgruppen? 20 Jahre Agenturen-Erfahrung

Die Vision war nie nur auf KMUs ausgerichtet. Von Anfang an wollte ich für zwei verschiedene Zielgruppen bauen:

KMUs (Kleine Unternehmen, 1-30 Mitarbeiter) – Der strategische Co-Gründer, den du dir leisten kannst:

- Können sich keine Marketing-Agenturen oder Berater leisten

- Haben kein strategisches Marketing-Fachwissen

- Brauchen schnelle Gewinne ohne steile Lernkurve

Agenturen (Verwaltung von 5-15+ Kunden) – Skaliere deine strategische Kapazität, nicht deine Mitarbeiterzahl:

- Ertrinken in Strategie-Arbeit über mehrere Kunden hinweg

- Brauchen konsistente Frameworks, die skalieren

- Erfordern vollständige Datenisolation zwischen Kunden

Warum Agenturen? Weil ich 20 Jahre auf der Agenturseite verbracht habe. Ich kenne den Schmerz aus erster Hand.

Ich habe Strategen gesehen, die 12 Kunden mit 12 verschiedenen Brand Guidelines jonglieren, Kontext zwischen Tools kopieren und einfügen und beten, dass sie nicht versehentlich die falsche Strategie an den falschen Kunden schicken. Ich habe Agenturen beobachtet, die gute Leute durch Burnout verlieren, weil es keine Möglichkeit gibt, strategisches Denken zu skalieren, ohne Mitarbeiterzahl zu skalieren.

Und ehrlich gesagt? Ich wollte mich herausfordern. Nur für KMUs zu bauen wäre einfacher – ein Nutzertyp, eine Organisation, unkompliziertes Routing. Für Agenturen zu bauen bedeutete Multi-Client-Dashboards, Datenisolation, rollenbasierte Berechtigungen, Client-bezogenes alles.

Ich wollte etwas Komplexes bauen. Etwas, das die schwierigen Probleme löst, die ich zwei Jahrzehnte lang gesehen habe.

Die Erkenntnis an Tag 2: Multi-Tenancy kann man nicht nachträglich einbauen

Hier ist, was ich an Tag 2 verstand, als ich auf mein einfaches Datenmodell starrte:

KMU-Architektur (was ich hatte):

```
users → campaigns → agent_outputs
```

Multi-Tenant-Architektur (was ich für Agenturen brauchte):

```
organizations (SME or AGENCY)
  ↓
clients (agencies only)
  ↓
campaigns
  ↓
agent_outputs (with org_id AND client_id)
```

Der Unterschied besteht nicht nur darin, "ein paar Spalten hinzuzufügen." Es ist ein grundlegend anderes Datenmodell.

Wenn ich erst für KMUs gebaut und Agenturen-Unterstützung später hinzugefügt hätte, würde ich Folgendes sehen:

- Migration jeder bestehenden Tabelle, um org_id hinzuzufügen

- Nachträgliches Einbauen von RLS-Richtlinien über die gesamte Datenbank

- Umschreiben des Frontend-Routings für Client-Kontext

- Neu-Testen von allem mit Multi-Tenant-Szenarien

Das ist keine Feature-Ergänzung. Das ist eine Neuprogrammierung.

Je länger ich wartete, desto teurer wurde die nachträgliche Anpassung. Tag 2 war günstig. Tag 60 wäre schmerzhaft. Tag 200 wäre "vielleicht bauen wir einfach ein separates Produkt für Agenturen."

Also habe ich die Entscheidung getroffen: Multi-Tenant von Tag 2 an bauen, oder akzeptieren, dass Agenturen niemals erstklassige Bürger sein würden.

Die Kompromisse: Was Multi-Tenancy tatsächlich kostet

Hier ist der Teil, bei dem ich hätte pausieren und mich fragen sollen: "Bist du sicher? Du hast EINEN funktionierenden Agenten. EINEN."

Aber ich habe nicht pausiert. Stattdessen begann ich, SQL-Schemas wie ein Verrückter zu schreiben. Multi-Tenancy an Tag 2 bedeutete, Kosten zu akzeptieren, die jeden vernünftigen Menschen zum Umdenken bringen würden:

Kosten 1: Entwicklungskomplexität (3-fach)

Jede Tabelle brauchte org_id. Agenturen-Tabellen brauchten client_id. RLS-Richtlinien brauchten beide Filter. Jede Abfrage, jeder API-Endpunkt, jede Frontend-Route – alles musste Multi-Tenant-bewusst sein.

Geschätzte Komplexitätszunahme: 3-fache Entwicklungszeit für gleiche Features.

(Spoiler: Es war eigentlich eher 4-fach. Ich hatte unterschätzt. Klassisch mein Fehler. :P)

Kosten 2: Verlängerter Entwicklungszeitplan

Von Anfang an für beide Zielgruppen zu bauen bedeutete einen längeren Weg zum Launch. So sah das aus:

Zeitplan:

- 20. August: Start des Aufbaus (Multi-Tenant von Tag 1)

- 15. September: 4 Wochen dabei, 3 Agenten funktionieren, Oktober angepeilt

- Oktober: 10 Tage krank, konnte nicht coden

- 5. November: Private-Alpha-Launch (75 Tage insgesamt)

Was Multi-Tenancy hinzugefügt hat:

- Schema-Routing zwischen public und agency Tabellen

- RLS-Richtlinien auf jeder Tabelle (am Ende 83 über 26 Tabellen)

- Client-Kontext-Propagierung durch jeden Agenten

- Doppelte Routing-Muster (KMU vs. Agenturen-URLs)

Hätte ich mit nur-KMU-Architektur schneller gestartet? Wahrscheinlich 3-4 Wochen schneller. Aber dann würde ich einer Neuprogrammierung ins Gesicht schauen, wenn Agenturen kommen.

Kosten 3: Sicherheitsanforderungen (höheres Risiko)

KMU-Datenisolation ist das Mindeste. Agenturen-Datenisolation ist unternehmenskritisch.

Hinzugefügte Anforderungen:

- 83 RLS-Richtlinien über 26 Tabellen

- Schema-Level-Isolation (public vs. agency Schemas)

- Datenbank-Router-Funktionen für jeden CRUD-Vorgang

- Umfassendes Audit-Logging

- Multi-Faktor-Authentifizierungs-Option

Sicherheitskomplexität: 5-fach höher als nur-KMU.

Ich habe manche Wochen mehr Zeit mit Row-Level-Security-Richtlinien als mit der tatsächlichen KI-Agenten-Entwicklung verbracht. Lass das sinken.

Kosten 4: Testkomplexität (2-fache Testfälle)

Jedes Feature musste getestet werden für:

- ✅ KMU-Fluss (einfacher)

- ✅ Agenturen-Fluss (client-bezogen)

- ✅ Datenisolation (Nike ≠ Adidas)

- ✅ Berechtigungsgrenzen (können Agenturen KMU-Daten sehen? Nein.)

Testpflege: Verdoppelt.

Weißt du, was Spaß macht? Denselben Test zweimal mit leicht unterschiedlichen Kontexten schreiben. Sagte nie jemand.

---

Warum ich den Kompromiss trotzdem eingegangen bin

Also lass mich das klarstellen: 3-fache Komplexität, verlängerter Zeitplan, 5-facher Sicherheitsaufwand, doppeltes Testen... und ich habe es trotzdem gemacht?

Ja. Hier ist die Überlegung (so sie war):

Grund 1: Nachträglicher Einbau ist ein Albtraum

Tag 2: Kaum Code geschrieben. Datenmodell noch flexibel. Keine Nutzer zum Migrieren.

Tag 60: 45 Tabellen, 200k Codezeilen, 15 Alpha-Nutzer. Multi-Tenancy hinzufügen würde bedeuten, die halbe Codebase umzuschreiben.

Lektion: Architekturentscheidungen werden exponentiell schwieriger zu ändern.

Kosten an Tag 2: ~5 Stunden, um das Datenmodell neu zu gestalten.

Kosten an Tag 60: ~200 Stunden, um alles zu refaktorieren.

Ich habe Unternehmen gesehen, die versucht haben, Multi-Tenancy nachträglich einzubauen. Es ist brutal. Du baust im Grunde das Flugzeug neu, während es fliegt. Mit Passagieren. Die dir bezahlen.

Grund 2: Ich verstehe Agenturen tatsächlich

Das war keine theoretische Marktforschung. Ich habe 20 Jahre damit verbracht, Agenturen beim Kampf mit genau diesem Problem zuzuschauen.

Ich weiß, dass sie brauchen:

- Vollständige Datenisolation (Kunde 1 kann Kunde 2's Strategie nicht sehen)

- Client-bezogenes alles (Brand Guidelines, Personas, Kampagnen)

- Rollenbasierter Zugang (Account Manager vs. Strategen)

- White-Label-Potenzial für Client-Präsentationen

Ich konnte das richtig bauen, weil ich den Schmerz gelebt hatte. Das ist kein Vorteil, den ich verschwenden wollte, indem ich nur-KMU shippe und "Agenturen später hinzufüge."

Grund 3: Die Herausforderung war der Punkt

Hier ist etwas, das ich nicht oft sage: Ich wollte die Komplexität.

Ich bin ein Gründer mittleren Alters mit Familie, kein 22-Jähriger, der mit Energy Drinks und wenig Schlaf überleben kann. Wenn ich ein Jahr damit verbringen soll, etwas zu bauen, sollte es besser etwas sein, das mich herausfordert. Etwas, auf das ich technisch stolz bin.

Multi-Tenant-Architektur mit ordentlicher Datenisolation, RLS-Richtlinien, Schema-Routing – das ist schwer. Das ist interessant. Das ist die Art von Technikproblem, das mich um 2 Uhr morgens beschäftigt hält.

Nur für KMUs zu bauen wäre schneller gewesen. Aber wäre ich genauso motiviert gewesen, durch die schwierigen Teile zu pushen? Wahrscheinlich nicht.

Grund 4: Beide Zielgruppen machen sich gegenseitig besser

KMUs und Agenturen sind keine konkurrierenden Use Cases. Sie ergänzen sich:

- Agenturen validieren das Produkt: Wenn Agenturen ihm mit Kundendaten vertrauen, werden KMUs es auch tun

- KMUs liefern Volumen: Mehr Nutzer bedeutet mehr Feedback, schnellere Iteration

- Architektur dient beiden: Team-Konten, Rollenberechtigungen und White-Label funktionieren für beide Zielgruppen

Für beide zu bauen bedeutete die vollständige Lösung zu bauen, nicht eine vereinfachte Version, der ich entwachsen würde.

Grund 5: Zukunftssicherung

Selbst über Agenturen hinaus hat Multi-Tenancy-Architektur ermöglicht:

- Team-Konten (KMUs mit mehreren Nutzern)

- Reseller-Partnerschaften

- White-Label-Möglichkeiten

- Enterprise-Verkäufe (falls ich jemals dorthin wollte)

Optionswert: Multi-Tenancy hat Geschäftsmodelle ermöglicht, die ich an Tag 2 noch nicht mal erahnen konnte.

Die Implementierung: Wie Architekturentscheidungen an Tag 2 aussahen

Hier ist, was ich am 21. August tatsächlich gebaut habe:

Datenbankschema (Kernentscheidung)

```sql
-- Organizations table (SME or AGENCY)
CREATE TABLE organizations (
  id UUID PRIMARY KEY,
  name TEXT,
  type TEXT CHECK (type IN ('SME', 'AGENCY')),  -- Kritische Unterscheidung
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Clients table (agencies only)
CREATE TABLE clients (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Welche Agentur besitzt das
  company_name TEXT,
  slug TEXT UNIQUE,  -- Für URL-Routing
  created_at TIMESTAMPTZ DEFAULT NOW(),

  -- Constraint: Nur Agenturen können Kunden haben
  CONSTRAINT clients_agency_only CHECK (
    (SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
  )
);

-- Campaigns table (Multi-Tenant-bewusst)
CREATE TABLE campaigns (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Immer erforderlich
  client_id UUID REFERENCES clients(id),      -- Erforderlich für Agenturen, null für KMUs
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Agent outputs (Multi-Tenant + Client-bezogen)
CREATE TABLE agent_outputs (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),
  client_id UUID REFERENCES clients(id),
  campaign_id UUID REFERENCES campaigns(id),
  agent_type TEXT,
  content JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW()
);
```

Schlüsselentscheidungen an Tag 2:

- org_id auf jeder Tabelle (ermöglicht RLS)

- client_id nullable (KMUs haben keine Kunden)

- type-Diskriminator auf Organisationen (KMU vs. AGENTUR)

- Constraint: Nur Agenturen können Kunden erstellen

Row-Level Security (Tag 2 Planung)

```sql
-- RLS-Richtlinie für Kampagnen (Multi-Tenant-Isolation)
CREATE POLICY campaigns_org_isolation ON campaigns
  FOR ALL TO authenticated
  USING (
    org_id = get_user_org_id() AND
    (client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
  );
```

Diese Richtlinie stellt sicher:

- ✅ Nutzer sehen nur Kampagnen ihrer Organisation

- ✅ Agenturen-Nutzer können keine KMU-Kampagnen sehen

- ✅ Agenturen können die Kunden anderer Agenturen nicht sehen

Kosten: 5 initiale RLS-Richtlinien an Tag 2 geschrieben. Wuchs bis zum Launch auf 83 an.

URL-Routing (Multi-Tenant von Tag 1)

```typescript
// Frontend-Routing-Struktur (Tag 2 geplant)

// KMU-Routen (einfach)
/campaigns/:campaignId
/agents/strategy/:campaignId

// Agenturen-Routen (client-bezogen)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```

Diese URL-Struktur ermöglicht:

- ✅ Client-Kontext in jeder URL (Agenturen)

- ✅ Klare Trennung zwischen KMU- und Agenturen-Flüssen

- ✅ Lesezeichenfähige, teilbare URLs

- ✅ Analytics-Tracking pro Client

Die Ergebnisse: Hat es sich ausgezahlt?

Launch-Datum: 5. November 2025 (75 Tage vom Start)

Entwicklungsaufwand durch Multi-Tenancy:

- Schema-Design und Migrationen

- 83 RLS-Richtlinien über 26 Tabellen

- Datenbank-Router-Funktionen

- Doppelte Routing-Muster (KMU vs. Agenturen-URLs)

- Client-Kontext-Propagierung

Mit Claude Code und Gemini 2.5 Pro ging das tatsächliche Coding schneller als es alleine gegangen wäre. Aber das Debuggen von RLS-Richtlinien, die eigentlich funktionieren sollten, aber nicht? Das ist um 2 Uhr morgens immer noch schmerzhaft, unabhängig von der KI-Unterstützung.

Was ich jetzt habe:

- Vollständige Datenisolation zwischen Organisationen

- Agenturen-bereite Architektur mit Client-Bezug

- 83 RLS-Richtlinien über 26 Tabellen

- Schema-Level-Routing (public vs. agency Schemas)

- White-Label-Potenzial von Tag 1 an eingebaut

- Ein Produkt, das tatsächlich sowohl KMUs als auch Agenturen richtig bedienen kann

Hat es sich ausgezahlt?

Frag mich in 6 Monaten, wenn ich echte Kunden habe, die echtes Geld bezahlen. Gerade befinde ich mich in der Private Alpha mit 15+ Nutzern und lerne noch, was funktioniert und was nicht.

Aber hier ist, was ich weiß: Ich habe die Architektur, um beide Zielgruppen richtig zu bedienen. Wenn ich nur KMU gebaut hätte und versucht hätte, Agenturen später hinzuzufügen, würde ich gerade einer 3-monatigen Neuprogrammierung ins Gesicht schauen. Stattdessen konzentriere ich mich auf Product-Market-Fit, nicht auf Architekturschulden.

Das fühlt sich wie der richtige Kompromiss an.

Das Framework: Wann Multi-Tenancy früh bauen

Nicht jedes Produkt braucht Multi-Tenancy an Tag 2. Verwende dieses Framework:

Multi-Tenancy früh bauen, wenn:

✅ Zielmarkt umfasst Agenturen/Reseller (höherer Wert pro Kunde)

✅ Datenisolation ist kritisch (gesetzliche/Compliance-Anforderungen)

✅ B2B mit Team-Konten wahrscheinlich (Slack, Figma-Modell)

✅ White-Label-Möglichkeiten existieren (Reseller-GTM-Strategie)

✅ Enterprise-Verkäufe sind möglich (brauchen Multi-Client von Tag 1)

Multi-Tenancy früh überspringen, wenn:

❌ B2C-Produkt (individuelle Nutzer, keine Organisationshierarchie)

❌ MVP braucht Geschwindigkeit (erst Product-Market-Fit testen)

❌ Kein Team/Agenturen-Use-Case (Einzelspieler-Tools)

❌ Einfaches Datenmodell (org_id später hinzuzufügen ist einfach)

❌ Solo-Gründer lernend (Komplexität könnte zu groß sein)

Gelernte Lektionen: Für deine Expertise bauen

1. Zielgruppenwissen sollte Architektur leiten

Nicht für hypothetische Nutzer entwerfen. Für Nutzer entwerfen, die du tatsächlich verstehst.

Mein Vorteil: 20 Jahre Agenturen-Erfahrung bedeuteten, dass ich genau wusste, was Agenturen brauchen – Datenisolation, Client-Bezug, rollenbasierter Zugang.

Falscher Ansatz: "Lass uns zuerst für KMUs bauen und Agenturen später hinzufügen, wenn wir sie besser verstehen"

Richtiger Ansatz: "Ich verstehe Agenturen bereits. Jetzt bauen, solange es günstig ist."

Wenn du tiefes Fachwissen in einem Marktsegment hast, nutze es. Lass dich nicht auf "erstmal einfacher" vertrösten.

2. Frühe Komplexität schlägt spätes Refactoring

Tag-2-Architekturkosten: 5 Stunden, um das Datenmodell neu zu gestalten.

Tag-60-Architekturkosten: 200 Stunden, um alles zu refaktorieren.

40-facher Unterschied.

Wenn du zu 80% sicher bist, dass du Multi-Tenancy brauchst, baue es früh. Je länger du wartest, desto teurer wird es.

3. Technische Herausforderung kann Motivation sein

Das ist persönlich: Ich wollte etwas Schwieriges bauen.

Multi-Tenant-Architektur mit RLS-Richtlinien, Schema-Routing und ordentlicher Datenisolation – das ist interessantes Ingenieurwesen. Es hat mich durch die schwierigen Teile engagiert gehalten.

Wenn du ein Solo-Gründer bist, unterschätze die Motivation nicht. Etwas zu bauen, das dich herausfordert, könnte mehr wert sein als schneller zu shippen.

4. Architektur ermöglicht Geschäftsmodelle

Multi-Tenancy war nicht nur eine technische Entscheidung. Sie hat ermöglicht:

- Agenturen-Preisstufen (wann immer ich Preisgestaltung herausfinde)

- White-Label-Möglichkeiten

- Enterprise-Verkaufspotenzial

- Team-Konten für KMUs

Architektur = Geschäftsoptionalität in Code-Form.

5. Solo-Gründer können Multi-Tenant bauen

"Multi-Tenancy ist zu komplex für eine Person" → Falsch.

Mit modernen Tools (Supabase RLS, Datenbankfunktionen, KI-unterstützte Entwicklung) können Solo-Gründer Enterprise-grade Multi-Tenancy bauen.

Zeitkosten: 70 Tage (Teilzeit).

Was du bekommst: Echte Datenisolation, kein Hack, den du später bereust.

Lohnt sich, wenn du beide Zielgruppen ernsthaft bedienen willst

Abschließende Gedanken

Tag 2 war viel zu früh, um zu wissen, ob STRAŦUM erfolgreich sein würde. Ich hatte einen Agenten. Keine Nutzer. Keine Validierung. Nur 20 Jahre Agenturen-Erfahrung, die mir sagten, was Agenturen tatsächlich brauchen.

Der verlängerte Zeitplan war manchmal schmerzhaft. Anderen Launches zuzuschauen, während ich noch RLS-Richtlinien debuggte und Datenbank-Router-Funktionen schrieb? Frustrierend beginnt es nicht zu beschreiben. Es gab Tage, an denen ich fragte, ob die Komplexität das Wert war.

Aber hier ist, was ich jetzt weiß: für beide Zielgruppen von Tag 1 an zu bauen war die richtige Entscheidung. Nicht wegen einer cleveren Unit-Economics-Berechnung – ich weiß immer noch nicht, welche Preisgestaltung funktionieren wird. Aber weil ich die Architektur habe, um beide Zielgruppen tatsächlich richtig zu bedienen.

Multi-Tenancy an Tag 2 war nicht nur eine technische Entscheidung. Es war eine Wette darauf, für Nutzer zu bauen, die ich tatsächlich verstehe, nicht für hypothetische Nutzer, die ich später herausfinden würde.

Hat sich diese Wette ausgezahlt?

Ich befinde mich noch in der Private Alpha mit 15+ Nutzern. Ich habe die Antwort noch nicht. Aber ich kann das sagen: Wenn eine Agentur sich meldet und fragt "Können wir das für mehrere Kunden mit ordentlicher Datenisolation nutzen?", kann ich ja sagen. Ich muss nicht sagen "Wir arbeiten daran."

Das fühlt sich wie das richtige Fundament an.

Die Zeit wird zeigen, ob ich ehrgeizig oder nur stur war. (Wahrscheinlich beides, ehrlich gesagt.) :)

Hast du jemals früh auf eine Architektur gesetzt, die zu dem Zeitpunkt zu ehrgeizig erschien – und hat es sich ausgezahlt? Ich würde gerne deine Geschichte hören.

Viele Grüße,

Chandler

Die STRAŦUM-Architektur-Serie: Diese Tag-2-Entscheidung war erst der Anfang. An Tag 67 musste ich die gesamte Multi-Tenancy-Schicht neu aufbauen, als ein Sicherheits-Audit Architekturmängel aufdeckte. Dann kamen 31 leere Bildschirme durch verlorenen Navigationskontext, und die Entdeckung, dass meine Datenbank technisch korrekt, aber 296-mal zu langsam war.

---

Baue ein Multi-Tenant SaaS? STRAŦUMs Architektur unterstützt sowohl KMU- als auch Agenturen-Kunden von Tag 1 an. Fordere Alpha-Zugang an unter https://stratum.chandlernguyen.com/request-invitation

---

Lerne noch, dass Architekturentscheidungen in Wirklichkeit Geschäftsentscheidungen sind. Debugge noch RLS-Richtlinien. Hinterfrage noch meine Tag-2-Entscheidungen (aber weniger jetzt). Mehr Bauabenteuer unter https://www.chandlernguyen.com/.

---