pagebee.de
Multi-Tenant-SaaS, mit dem Unternehmen ihre Webseite per Chat mit einer KI individuell anpassen: eigenes Git-Repo pro Kunde, Vorschau, Netlify-Deploy auf Freigabe.
Kleine Unternehmen können sich für jede geänderte Öffnungszeit oder jedes neue Hero-Foto keinen Entwickler leisten, brauchen aber trotzdem moderne, schnelle Webseiten. Pagebee löst das per Chat: im Editor genügt 'tausch das Hero-Foto und ändere die Öffnungszeiten auf 8-18', ein 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. Jede Kundenseite bekommt ein isoliertes Repo, plan-basierte Sicherheitsregeln und eine vollständige Revisionshistorie. Fürs Onboarding gibt es außerdem eine eigene Claude-Code-Pipeline: Sie liest die bestehende Webseite eines Interessenten aus und baut daraus automatisch eine moderne React-Version. Läuft als Multi-Tenant-SaaS auf pagebee.de.
Technische Details
Stack, Architektur, Trade-offs
Technologien
Runtime
Modelle
Storage
Auth
Realtime
Infra
Vom Chat zum Deploy
Eine Session, sieben Schritte. Alles wartet auf eine Freigabe vor dem Live-Push: Preview-First by default.
- 1
Im Editor-Chat landet der Auftrag: '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
Preview prüfen, Deploy drücken → Push auf main, Netlify-Production-Build.
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
Pro Plan konfigurierbar: maxFilesChanged, maxLinesChanged, maxTotalDiffBytes, allowedPaths, allowLayoutChanges. 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. Im Editor sichtbar: '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.
Trade-offs
Wo das System Reibung verursacht, und wofür.
Tenant-Repo statt DB-Versionen
Eigenes Git-Repo pro Kunde macht Revisionen, Rollbacks und Vorschauen zu reinen git-Operationen. Im Gegenzug: mehr Disk-I/O, Backup-Komplexität pro Kunde, nicht-trivialer Storage-Footprint. Bewusst bezahlt, um keine eigene Versionsverwaltungs-Schicht bauen und pflegen zu müssen.
Validierung beim Abschluss, nicht pro Tool-Call
Komplexitätsregeln werden am Ende gegen den aggregierten Diff geprüft, nicht bei jedem einzelnen Tool-Aufruf. Folge: die KI verbrennt gelegentlich Tokens auf Arbeit, die der finalize-Step dann abweist. Gewinn auf der anderen Seite: die Editor-UX bleibt durchgehend ruhig. Kein zickiges Tool, das mitten in einer Aktion 'BLOCKED' wirft.
Provider-agnostischer Tool-Loop (Claude + OpenAI)
Beide Provider arbeiten gegen dasselbe Tool-Schema und denselben Event-Stream. Das heißt im Klartext: keine extended-thinking-Modi, kein provider-spezifisches Prompt-Caching, kein Vision-Input. Was übrig bleibt, sind ein stabiles Datenmodell und der erste Modell-Wechsel als reine Config-Änderung statt als Migration.
Hartes Token-Budget pro Edit-Request
Datei-Inhalte, Suchergebnisse und Konversationshistorie werden vor jedem Provider-Aufruf auf harte Limits getrimmt. Konsequenz: die KI wird gelegentlich mitten im Gedanken abgeschnitten und muss neu ansetzen. Dafür bleiben die Kosten auf Basic-Plänen vorhersagbar; 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. Was fehlt: ein gemeinsames Fortschritts-UI und ein geteilter Auth-Kontext. Was zählt: Onboarding-Tooling und Laufzeit-SaaS deployen sich nicht gegenseitig und lasten sich nicht gegenseitig aus.
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. |
Onboarding-Pipeline - 6 Phasen
Eigener Claude-Code-Prozess fürs Onboarding: Er liest die bestehende Webseite eines Interessenten aus und baut daraus automatisch eine moderne React-Version. 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
mittelBranchen-Recherche, Sitemap, Design-Richtung.
3. Content & Design
mittelPro-Seiten-Copy, Design-Tokens, Bild-Auswahl.
4. Implement
hochAus reichem Template Header / Footer / Forms / SEO; nur Seiten-Inhalte werden neu geschrieben.
5. QA & Verify Build
niedrignpm run build muss grün sein; Lint und Visual-Checks.
6. Sales Pitch
niedrigGeneriert ein Verkaufsgespräch-Skript für Cold-Outreach.
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.