Ob eine B2B-SaaS-Marketing-Seite mit Claude Code gebaut werden kann, ist seit etwa einem Jahr keine offene Frage mehr. Es gibt genug dokumentierte Fälle, inzwischen auch auf Deutsch. Die Zahlen darin sind unspektakulär gut. Ein Anbieter aus Spanien hat sein Git-Log offengelegt: 639 Änderungen über anderthalb Jahre, 345 Blogposts, fünf Sprachen. Ein anderer war vom ersten Commit bis zum Produktivbetrieb rund fünf Wochen unterwegs.
Die offene Frage ist eine andere und sie stellt sich erst später. Sie lautet: Wer ändert nächsten Dienstag den Preis auf der Preisseite, wenn die Person, die alles gebaut hat, gerade in Portugal ist.
Dieser Artikel handelt vom zweiten Jahr. Der Bau kommt nur so weit vor, wie er den Betrieb bestimmt.
Was der Bau wirklich kostet
Die belastbarste Aufstellung stammt von einem Betreiber, der seine Jahresrechnung offengelegt hat: rund 20 US-Dollar im Monat für das Abo während der Bauphase, 15 im Jahr für die Domain, Hosting kostenlos. Unter 100 US-Dollar im ersten Jahr für 24 Seiten und 13 Blogposts. Der Initialbau lief an einem Wochenende, die vollständige Seite über mehrere Wochen.
Ein deutscher Betreiber hat vorher und nachher gegenübergestellt. Vorher ein WordPress-Stack mit rund 73 Euro monatlich, verteilt auf Hosting, Caching-Plugin, SEO-Plugin, Backup, Firewall, Formular und Newsletter-Erweiterungen. Danach rund 17 Euro. Die interessantere Zahl in seinem Bericht ist aber nicht die Ersparnis. Er hat eine Woche lang mitgeschrieben und kam auf 6,5 Stunden reine Verwaltung in dieser Woche. Ungefähr so viel, wie er für Inhalte aufgewendet hat.
Und jetzt der Teil, der in fast jeder dieser Rechnungen falsch ist.
Die Null beim Hosting stimmt für eine Firmenseite nicht. Vercels Hobby-Plan ist laut Fair-Use-Richtlinie auf nicht-kommerzielle, private Nutzung beschränkt. Der Pro-Plan kostet 20 US-Dollar pro Nutzer und Monat. Derselbe Vorbehalt gilt sinngemäß für andere kostenlose Stufen, die in solchen Aufstellungen auftauchen. Für ein B2B-SaaS-Unternehmen heißt das realistisch: 20 im Monat statt null, oder ein Anbieter, dessen kostenlose Stufe kommerzielle Nutzung ausdrücklich erlaubt.
Rechne für den laufenden Betrieb also mit dem Abo, dem Hosting und der Domain. Das bleibt günstig. Es ist nur nicht null.
Der erste Tag danach
Die Szene, an der sich alles entscheidet, ist unspektakulär. Das Pricing ändert sich, die Startseite und die Preisseite müssen angepasst werden. Und zwar heute.
Wer das dann macht, hängt an genau einer Frage: Was habt ihr beim Bau über die Pflege entschieden. Wenn die Antwort lautet "das machen wir später", macht es die Person, die gebaut hat. Immer. Und wenn die nicht da ist, wartet die Änderung.
In den ausgewerteten Erfahrungsberichten ist diese Abhängigkeit kein Nebeneffekt, sie ist die Struktur. Von sieben Fällen sind vier Einzelpersonen. Einer ist ein Zweierteam mit genau einer Person, die Änderungen freigibt. Nur ein einziger Bericht beschreibt einen echten Redaktionsbetrieb mit mehreren Beteiligten.
Vier Wege, Inhalte zu pflegen
Es gibt genau vier. Jeder hat einen Preis. Die Entscheidung dafür gehört an den Anfang des Projekts, nicht ans Ende.
Dateien im Repository
Jeder Blogpost ist eine Datei, jede Branchenseite ein Datensatz. Navigation und Übersichtsseiten aktualisieren sich daraus selbst. Als Sicherheitsnetz prüft der Build, ob Pflichtfelder fehlen. Fehlt eines, bricht er ab.
Sauber, schnell, ohne laufende Kosten. Der Preis: Wer Inhalte pflegen will, muss mit Dateien und Versionsverwaltung umgehen können. Der Betreiber, der diesen Weg dokumentiert hat, rechnet mit zwei bis drei Stunden Inhaltsarbeit pro Woche und ist die einzige Person im System.
Ein Redaktionsprozess statt eines Systems
Eine deutsche Agentur hat das über Vorlagen im Ticketsystem gelöst. Jemand legt ein Ticket an, die KI erzeugt daraus den Text samt Übersetzung, jemand anderes prüft, das Zusammenführen löst die Veröffentlichung aus.
Ihr Argument: Niemand muss ein Redaktionssystem lernen. Der unausgesprochene Preis: Jede Person in der Redaktion muss stattdessen GitHub bedienen können. Das ist kein Fortschritt, das ist ein Tausch.
Jedes Mal wieder die KI fragen
Terminal im Projektordner öffnen, Claude Code starten, den Beitrag diktieren, prüfen, veröffentlichen. Der deutsche Betreiber von oben beziffert das auf 30 bis 45 Minuten bis live, gegenüber vorher vier bis sechs Stunden.
Funktioniert gut. Der Preis: Es funktioniert, weil er allein arbeitet und technisch versiert ist. Bei zwei Personen mit unterschiedlichem Kenntnisstand bricht es.
Ein Headless-CMS davorsetzen
Der Weg, den ein Anbieter gewählt hat, nachdem der Vorgängerbau weder Inhaltstypen noch Redaktionsabläufe hatte. Ab rund 18 US-Dollar im Monat, plus einmal jemanden, der die Inhaltsstruktur sauber anlegt.
Der Preis: laufende Kosten und ein Stück Einrichtung. Dafür ist es der einzige der vier Wege, bei dem eine Marketing-Kollegin ohne technischen Hintergrund selbstständig arbeitet.
Dazu ein Einwand, der es verdient, ernst genommen zu werden. Der Inhaber einer Agentur mit 60 Leuten hat im Mai 2026 aufgeschrieben, dass praktisch jede Anfrage bei ihm den Wunsch enthält, Inhalte, Blöcke und Seiten selbst anlegen zu können. Sein Argument ist kein technisches: Marketing-Leute sollen Kampagnen machen und nicht alle sechs Monate lernen, wie die Webseite jetzt funktioniert. Ein Ablauf, der voraussetzt, dass jemand eine Kommandozeile bedient, einen brauchbaren Prompt schreibt und Änderungen zusammenführt, schließt genau die Leute aus, für die ein Redaktionssystem erfunden wurde.
Das ist Meinung. Es ist Meinung aus dem Tagesgeschäft mit Marketing-Teams. Sie deckt sich mit dem, was wir bei Webseiten für B2B-SaaS regelmäßig sehen.
Die drei Bruchstellen, die niemand einplant
Die Person, die gebaut hat, ist weg
Der Effekt hat einen Namen. Addy Osmani nennt ihn Comprehension Debt, also die Lücke zwischen vorhandenem Code und tatsächlich verstandenem Code.
Der Mechanismus ist unangenehm: Technische Schulden melden sich über Reibung, irgendwas ist mühsam, irgendwas dauert. Verständnisschulden fühlen sich gut an. Der Code sieht sauber aus, die Tests laufen grün. Niemand merkt etwas, bis eine Änderung ansteht.
Dazu gibt es eine kontrollierte Untersuchung mit 52 Entwicklern. Die Gruppe mit KI-Unterstützung war genauso schnell fertig, schnitt aber im anschließenden Verständnistest um 17 Prozentpunkte schlechter ab, 50 gegen 67 Prozent. Am deutlichsten war der Abstand bei der Fehlersuche. Also genau dort, wo es im Betrieb weh tut.
Was dagegen hilft, ist banal und wird trotzdem nie gemacht. Ein aufgezeichneter Rundgang durch die Architektur, 60 bis 90 Minuten. Eine schriftliche Liste aller Umgebungsvariablen und Zugänge. Eine Liste der Stellen, von denen die bauende Person weiß, dass sie fragil sind.
Nach sechs Monaten weiß niemand mehr, warum etwas so ist
Auch dafür gibt es einen belegten Fall statt einer Warnung. Ein Betreiber hat seinen eigenen Erfahrungsbericht nachträglich korrigiert und mit einem Prüfdatum versehen, weil die ursprüngliche Fassung die Architektur falsch beschrieb. Die Rede war von einem bestimmten Backend, tatsächlich lief etwas anderes. Seine Begründung für die Korrektur trifft den Kern: Eine falsche Architekturbeschreibung schickt den nächsten Bearbeiter ins falsche System.
Dazu kommt ein Effekt aus der Arbeit selbst. In sehr langen Sitzungen vergisst das Modell Regeln, die am Anfang gesetzt wurden. Ein Betreiber beschreibt, dass nach fünf Stunden wieder Bausteine vorgeschlagen wurden, die am selben Morgen ausgeschlossen worden waren.
Daraus folgt eine harte Regel für den Betrieb: Was nicht schriftlich im Projekt steht, existiert beim nächsten Mal nicht. Entscheidungen gehören in eine Datei im Repository, nicht in den Kopf und nicht in einen Chatverlauf.
Zwei Leute wollen gleichzeitig etwas ändern
Der einzige Bericht mit echtem Team-Prozess hat dafür fünf Regeln. Sie klingen wie das, was eine Redaktion ohnehin braucht:
- Erst die Spezifikation, dann das Werkzeug öffnen.
- Jede KI-Änderung auf einen eigenen Zweig, nie direkt auf den Hauptzweig.
- Automatische Prüfungen als Netz. Konkret: ein Prüfer für Übersetzungen, einer für Bilder und ein Test auf interne Links.
- Review in thematischen Blöcken statt 50 Dateien am Stück.
- Die Beschreibung einer Änderung schreibt immer ein Mensch.
Der dritte Punkt ist der wichtigste und der am wenigsten offensichtliche. Die Prüfungen existieren, weil die KI Inhalte erzeugt, die formal fehlerfrei und inhaltlich falsch sind. Ein Link auf eine Seite, die es nicht gibt. Ein Verweis auf ein Bild, das nie erzeugt wurde. Im selben Projekt hat eine frühere KI-Änderung interne Links zerschossen, gefunden wurde das erst Wochen später in einer Review.
Was am Bau dranhängt und im Alltag zurückkommt
Weiterleitungen sind der einzige Fehler hier, der direkt Umsatz kostet. Und es gibt zwei belegte Gegenbeispiele, wie es richtig geht. Ein Betreiber hat aus einem Search-Console-Export eine Liste mit 474 Weiterleitungen gebaut, in den ersten zwei Stunden rund 80 alte Adressen von Hand geprüft, dabei drei Sonderfälle gefunden und seine rund 250 Rankings gehalten. Ein zweiter hat Einzelartikel über Aliase und Strukturmuster über Server-Regeln gelöst, ebenfalls ohne Einbruch. Wie das im größeren Rahmen abläuft, steht im Fahrplan für den Relaunch ohne Sichtbarkeitsverlust.
Metadaten und strukturierte Daten laufen mit, aber nur wenn du sie nennst. Ein Betreiber listet auf, was bei ihm drin ist: strukturierte Daten für Organisation, Leistung, FAQ, Artikel und Brotkrumen-Navigation, eine robots.txt mit Regeln für KI-Crawler, eine XML-Sitemap mit Prioritäten und Vorschaubilder für soziale Netzwerke auf jeder Seite. Von allein entsteht davon nichts.
Analytics und Einwilligung sind im DACH-Raum kein Nebenschauplatz. Der Landesbeauftragte für Datenschutz Baden-Württemberg stellt klar: Einwilligung braucht es für externe Analyse-Werkzeuge, für Wiedererkennung über die Sitzung hinaus und für Weitergabe an Dritte. Ohne Einwilligung geht die lokale Auswertung ohne Cookies und ohne Wiedererkennung. Und ausdrücklich: Serverseitiges Tracking muss die DSGVO genauso erfüllen, das bloße Ersetzen von Kennungen ist keine Anonymisierung. In einem der ausgewerteten Berichte wird das Gegenteil behauptet. Das ist ein Einzelfall und kein Rezept.
Formulare landen irgendwo. In den Berichten sind das Mailversand-Dienste, Chat-Weiterleitungen und Funktionen beim Hosting-Anbieter. Für den Betrieb in Deutschland heißt jeder dieser Dienste einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO. Diese Frage taucht beim Bauen nie auf und beim ersten Datenschutz-Audit sofort.
Wofür es reicht und ab wann nicht mehr
Belegt tragfähig ist der Weg für:
- Menge statt Entscheidung. Zwanzig ähnlich aufgebaute Seiten sind der Idealfall. Ob es diese zwanzig Seiten geben sollte, bleibt deine Aufgabe.
- Konsistenz über viele gleichartige Dateien. Menschen sind da von Natur aus unzuverlässig, das Modell nicht.
- Kleine Helfer, die niemand kaufen würde. Link-Prüfer, Sitemap-Erzeuger, Übersetzungsabgleich.
- Das unsichtbare SEO-Handwerk, das sonst Stunden Handarbeit und Debugging gegen den Google-Validator bedeutet.
- Umzüge mit Ranking-Erhalt, zweifach unabhängig belegt.
Nicht mehr tragfähig ist er:
- Ohne irgendeinen Entwickler im Kreis. Das ist die klarste Grenzaussage der gesamten Recherche. Sie kommt von jemandem, der den Weg gegangen ist und ihn empfiehlt.
- Ab mehreren nicht-technischen Redakteuren. Wer eine fünfköpfige Marketing-Abteilung hat, nimmt ein Headless-CMS oder bleibt bei dem, was schon läuft.
- Beim ersten Wurf. Die meisten Funktionen brauchten drei bis fünf Durchläufe. Nichts saß beim ersten Versuch.
- Bei Markenstimme und Gestaltung. "Mach das Design besser" führt zu nichts. "3px linke Kante in Mint auf Zitaten" führt zum Ziel. Ohne enge Vorgaben landest du bei einer Seite, die aussieht wie alle anderen.
Der ehrlichste Satz dazu stammt von einem Gründer, der von einem Baukasten zu Claude Code gewechselt ist: Seiten bauen ist billig geworden. Der neue Engpass ist die Entscheidung, was ein Besucher überhaupt sehen soll. Dazu die Messung, ob es wirkt. Genau deshalb ist die Werkzeugfrage die kleinere. Welche das für euch ist, haben wir im Vergleich der Wege für eine B2B-SaaS-Webseite aufgeschlüsselt.
Damit es den Bau überlebt
Fünf Bedingungen, jede aus einem der Fälle oben abgeleitet:
- Jede Änderung über einen eigenen Zweig mit Review. Auch die von der KI. Besonders die.
- Automatische Prüfungen für interne Links, Bilder und Pflichtfelder. Sie fangen genau die Fehlerklasse, die Menschen übersehen.
- Die Architektur schriftlich im Repository. Eine Seite reicht, aber sie muss stimmen und ein Prüfdatum tragen.
- Zugänge und Umgebungsvariablen dokumentiert, an einer Stelle, die nicht im Kopf einer Person liegt.
- Ein Redaktionsweg für Nicht-Technische, entschieden vor dem Bau. Wenn ihr keinen wollt, ist das eine Entscheidung. Sie wird nur meistens nicht getroffen, sondern vergessen.
Der Bau ist das billige Drittel. Was darüber entscheidet, ob die Seite in zwei Jahren noch gepflegt wird, ist die Übergabe. Wenn ihr das lieber gleich richtig aufsetzen wollt, ist das genau unsere Arbeit.
