pagebee.de

Multi-Tenant-SaaS, mit dem Unternehmen ihre Webseite per Chat mit einer KI individuell anpassen — eigener Git-Repo pro Kunde, Vorschau, Netlify-Deploy auf Freigabe.

Schlüsselentscheidung

Pro Kunde ein echter Git-Repo (statt DB-Versionsstrings). Revisionen, Rollbacks und Vorschauen werden damit zu reinen git-Operationen — kein eigener Versionsmechanismus, kein Custom-Diff. Kosten: mehr Disk-I/O, weniger triviales Backup. Bezahlt sich aus, sobald der erste Kunde 'das war gestern noch anders' sagt.

Ein Nicht-Techniker sagt 'tausch das Hero-Foto und ändere die Öffnungszeiten auf 8-18'. Der Orchestrator übersetzt das in Tool-Calls auf das eigene Git-Repo des Kunden, committet auf einen Draft-Branch, rendert eine Vorschau und wartet auf Freigabe. Jeder Kunde bekommt ein isoliertes Repo, plan-basierte Sicherheitsregeln und eine vollständige Revisionshistorie. Daneben läuft eine separate Claude-Code-Pipeline, die für neue Kunden eine bestehende Webseite scrapet und einen modernen React-Klon bootstrappt.

Vom Chat zum Deploy

Eine Session, sieben Schritte. Alles wartet auf eine Freigabe vor dem Live-Push — Preview-First by default.

1
Kundin schreibt im Editor: 'tausch das Hero-Foto und ändere die Öffnungszeiten auf 8-18'.
2
Edit-Request landet in der Postgres-Queue mit Status PENDING → RUNNING.
3
Orchestrator initialisiert eine Session mit Site-Kontext, Plan-Regeln und Tool-Set.
4
Tool-Loop: AI exploriert das Repo, liest Content-Dateien, editiert gezielt. Live-Events fließen per WebSocket in die UI.
5
AI ruft finalize_edit_with_commit; Komplexitätsregeln werden gegen den Plan validiert.
6
Bei OK: Commit auf Draft-Branch, Netlify-Preview, Revision-Record erstellt.
7
Kundin sieht die Preview, drückt Deploy → Push auf main, Netlify-Production-Build.

Architektur — Turborepo-Monorepo

Vier interne Packages plus die Next.js-App. Tenant-Repos und Onboarding-Pipeline laufen außerhalb des SaaS-Runtimes.

Pfad	Wofür
apps/studio/	Next.js Admin- und Kunden-UI (Editor, Vorschau, Revisionen, Billing).
packages/core/	Geteilte Typen, Plan-Regeln, Defaults.
packages/ai-orchestrator/	Provider-Interface (Claude / OpenAI), Tool-Loop, Event-Stream.
packages/git-adapter/	Tenant-isolierte Git-Operationen (Checkout, Diff, Commit, Branch).
packages/netlify-adapter/	Site-Provisioning, Preview-Deploys, Production-Deploys via Netlify-API.
prisma/	Schema und Migrationen für Auth, Tenants, Revisionen, Pipeline-Queue.
repos/{slug}/	Echter Git-Repo pro Kunde (gitignored aus dem Monorepo).
pipeline_updated/	Separate Claude-Code-Pipeline, die Bestandsseiten scrapet und neue React-Sites bootstrappt.
bot/	Telegram-Bot, der die Onboarding-Pipeline aus dem Chat anstößt.

Tool-Loop — 8 Tools

Der Loop ist provider-agnostisch: Claude (Default) und OpenAI teilen sich exakt dieses Tool-Schema und einen gemeinsamen Event-Stream.

Tool	Beschreibung
list_project_files	Listet Dateien des Projekts, optional mit Glob-Filter.
search_files	Volltextsuche durch das Tenant-Repo.
read_project_file	Liest eine Datei relativ zum Project-Root.
edit_file	Gezielte String-Ersetzung in einer existierenden Datei.
write_project_file	Schreibt eine Datei (neu oder überschreiben).
delete_project_file	Löscht eine Datei aus dem Repo.
summarize_project_changes	Aggregierter Diff: geänderte Dateien, +/-Zeilen.
finalize_edit_with_commit	Schließt die Session: validiert Komplexitätsregeln, committet, deployt die Vorschau.

Plan-Sicherheitsregeln — Basic vs Pro

Regeln werden zur Finalize-Zeit gegen den aggregierten Diff geprüft — nicht pro Tool-Call. Verstöße resetten die Änderungen und setzen den Edit auf BLOCKED_COMPLEXITY.

Regel	Basic	Pro
Maximale Dateien pro Edit	5	50
Maximale Zeilen pro Edit	80	1000
Maximale Diff-Größe	10 KB	100 KB
Erlaubte Pfade	content/, public/uploads/	**
Layout-Änderungen	—	✓

Onboarding-Pipeline — 6 Phasen

Separater Claude-Code-Prozess, der für neue Kunden eine bestehende Webseite scrapet und einen modernen React-Klon bootstrappt. Vite + React 18 + Tailwind, Netlify-Forms und -Hosting.

1. Scrape & Analyze

niedrig (scripted)

Bestehende Webseite mit eigenem Scraper extrahieren — Text, Bilder, Farben, Fonts, Struktur.

2. Research & Plan

mittel

Branchen-Recherche, Sitemap, Design-Richtung.

3. Content & Design

mittel

Pro-Seiten-Copy, Design-Tokens, Bild-Auswahl.

4. Implement

hoch

Aus reichem Template Header / Footer / Forms / SEO; nur Seiten-Inhalte werden neu geschrieben.

5. QA & Verify Build

niedrig

npm run build muss grün sein; Lint und Visual-Checks.

6. Sales Pitch

niedrig

Generiert ein Verkaufsgespräch-Skript für Cold-Outreach.

Schlüsselentscheidungen

Tenant-isolierte Git-Repos statt DB-Strings

Jede Kundenseite ist ein echter Git-Repo unter repos/{slug}. Revisionen, Rollbacks und Previews sind dadurch reine git-Operationen — kein eigener Versionsmechanismus, kein Custom-Diff.

Provider-agnostischer Tool-Loop

Claude und OpenAI teilen sich ein einziges Tool-Schema und einen gemeinsamen Event-Stream. Der Provider ist pro Edit-Request umschaltbar — environment-default, request-override.

Token-Budget strikt durchgesetzt

Datei-Inhalte, Suchergebnisse und Konversationshistorie werden auf harte Limits getrimmt, bevor sie an den Provider gehen. Kosten bleiben auf Basic-Plänen vorhersagbar — der Orchestrator wird nicht zur Kostenfalle.

Plan-basierte Sicherheitsregeln

maxFilesChanged, maxLinesChanged, maxTotalDiffBytes, allowedPaths, allowLayoutChanges — pro Plan konfigurierbar. Basic-Pläne sehen nur content/** und public/uploads/**, Pro-Pläne haben Layout-Zugriff. Validierung läuft beim Abschluss-Schritt, nicht bei jedem Tool-Call.

Live-Activity-Stream über WebSocket

Tool-Calls und Modell-Deltas werden in Echtzeit an die Editor-UI gestreamt. Die Kundin sieht 'KI liest content/hero.md', 'editiert ...', 'commit' — keine Blackbox, kein wortloser Spinner.

Onboarding-Pipeline als separater Prozess

Die 6-Phasen-Pipeline läuft NICHT als Studio-Subprozess — sie ist ein eigenes Claude-Code-Setup mit eigenen Skills (skills/) und kann unabhängig vom Studio betrieben werden. Telegram-Bot triggert. Sauberer Schnitt zwischen Onboarding-Tooling und Laufzeit-SaaS.

Tradeoffs — offen genannt

Die unangenehmen Entscheidungen, die in den meisten Demos versteckt werden. Hier sichtbar gemacht.

Tenant-Repo statt DB-Versionsstrings

Eigener git-Repo pro Kunde macht Revisionen, Rollbacks und Vorschauen zu reinen git-Operationen. Kosten: mehr Disk-I/O, Backup-Komplexität pro Kunde, nicht-trivialer Storage-Footprint. Bezahlt sich aus, sobald der erste Kunde 'das war gestern noch anders' sagt.

Validierung beim Abschluss, nicht pro Tool-Call

Komplexitätsregeln laufen gegen den aggregierten Diff am Ende. Kosten: Die KI verbrennt manchmal Tokens auf Arbeit, die am finalize-Step abgewiesen wird. Bezahlt sich aus, weil die Editor-UX glatt bleibt — kein zickiges Tool, das mitten in einer Aktion 'BLOCKED' wirft.

Provider-agnostischer Tool-Loop (Claude + OpenAI)

Beide Provider teilen sich exakt ein Tool-Schema und einen gemeinsamen Event-Stream. Kosten: Tool-Definitionen müssen den größten gemeinsamen Nenner treffen — kein extended thinking, kein provider-spezifisches Prompt-Caching, kein Vision-Input. Bezahlt sich aus, weil das Datenmodell beim ersten Modell-Wechsel nicht reißt.

Hartes Token-Budget pro Edit-Request

Datei-Inhalte, Suchergebnisse und Konversationshistorie werden vor jedem Provider-Aufruf auf harte Limits getrimmt. Kosten: Die KI wird gelegentlich mitten im Gedanken abgeschnitten und muss neu ansetzen. Bezahlt sich aus, weil Basic-Pläne Kosten-vorhersagbar bleiben — der Orchestrator wird nicht zur Kostenfalle.

Onboarding-Pipeline als eigener Prozess

Die 6-Phasen-Pipeline für Neukunden läuft nicht im Studio-Runtime, sondern als eigenes Claude-Code-Setup mit eigenen Skills. Kosten: kein gemeinsames Fortschritts-UI, kein geteilter Auth-Kontext. Bezahlt sich aus, weil Onboarding-Tooling und Laufzeit-SaaS sich nicht gegenseitig deployen oder lasten.

Was bewusst draußen ist

Echtzeit-Multi-User-Bearbeitung am selben Site-Stand — eine Kundin pro Seite, Konflikte werden über git-Branches statt CRDT gelöst.
Mobile Editor-UI — Capture via Telegram-Bot funktioniert mobil, das eigentliche Editieren ist Desktop-only.
Theme-Marketplace — alle Sites sitzen auf einem geteilten shadcn-basierten Template; Customization ist per-Kunden-Repo, nicht über austauschbare Themes.
Auto-SEO — die KI schreibt keine Meta-Tags oder Sitemaps selbständig, das bleibt ein expliziter Kunden-Request.
Öffentliche Preview-URLs — jede Vorschau ist auth-gegated, kein 'teil den Link mit deinem Chef'.
i18n pro Site — jede Kundenseite ist einsprachig; Multi-Language ist ein eigenes Projekt-Setup.

Deployment

Docker-Compose für lokales Postgres; Studio läuft als Next.js-App. Netlify übernimmt das eigentliche Hosting der Kundenseiten — sowohl Previews als auch Production-Builds. nginx-Preview-Konfiguration für selbst-gehostete Vorschauen ist als Fallback dabei.