So bauen Sie mit Claude Code eine Website, die nicht schrecklich aussieht

Kurze Antwort: Mit Claude Code können Sie eine Website bauen, die gestaltet statt generiert aussieht, aber nur, wenn Sie verhindern, dass es auf seine Standardwerte zurückfällt. Geben Sie ihm ein echtes Designsystem in Form von Tokens, halten Sie Ihre Regeln in einer CLAUDE.md-Datei und einer Spezifikation fest, bauen Sie in kleinen Phasen, die ein Mensch freigibt, und richten Sie Prüfungen für Kontrast, Tokens, Barrierefreiheit und Geschwindigkeit ein, die den Build scheitern lassen, sobald etwas abweicht.

Die meisten Marketer, die das ausprobieren, erleben dasselbe. Die erste Seite ist schnell da und wirkt auf den ersten Blick gut. Dann fallen die Schriftart Inter, der violette Farbverlauf, die zentrierte Überschrift über zwei Buttons und drei identische Karten auf, und Ihnen wird klar, dass Sie genau diese Website schon unzählige Male gesehen haben.

Dieser Leitfaden richtet sich an Marketer und Gründer, die mit Claude Code eine Marketing-Website bauen oder neu aufsetzen und am Ende ein Ergebnis möchten, das nach ihrer Marke aussieht. Er erklärt, warum KI-gebaute Websites generisch wirken, was Sie Claude geben sollten, bevor es die erste Zeile schreibt, wie Sie es während des Baus auf Kurs halten und wie Sie eine alte Website ersetzen, ohne Suchtraffic zu verlieren. Die durchgehende Fallstudie ist saas-hackers.com selbst, im November 2026 mit Claude Code von Webflow aus neu aufgebaut. Alle zitierten Ergebnisse dieses Projekts stammen aus den eigenen Aufzeichnungen.

Lässt sich mit Claude Code eine Website bauen, die gut aussieht?

Claude Code ist ein KI-Coding-Tool, das Ihr Projekt liest, Code schreibt und bearbeitet, Befehle ausführt und seine eigene Arbeit prüft. Für eine Marketing-Website heißt das: Es kann das Framework einrichten, die Komponenten bauen, ein CMS anbinden und die Tests ausführen, während Sie entscheiden, was die Website sein soll und ob jeder Schritt gut genug ist.

Ja, wenn Sie die richtige Arbeit drumherum leisten. Claude Code ist stark in der Entwicklung und schnell bei den repetitiven Teilen eines Builds. Es kennt weder Ihre Marke noch Ihre Käufer noch die Entscheidungen, die Ihr Team in einem Meeting getroffen hat, und füllt diese Lücken mit der häufigsten Wahl, die es kennt. Ob die Website gut aussieht, entscheidet sich bei der Arbeit vor und neben dem Build: Designsystem, schriftliche Regeln und Prüfungen.

Wenn Sie noch nicht festgelegt haben, was die Website für Ihre Pipeline leisten soll, beginnen Sie mit unserem Leitfaden zur Website-Strategie für B2B-SaaS. Dieser Leitfaden setzt voraus, dass Sie wissen, welche Seiten Sie brauchen, und sie gut umsetzen wollen.

Warum sehen KI-generierte Websites alle gleich aus?

KI-gebaute Websites sehen gleich aus, weil Sprachmodelle die jeweils wahrscheinlichste nächste Wahl treffen und die wahrscheinlichste Wahl im Webdesign die sichere ist. Anthropic nennt das „distributional convergence“: Sichere Designentscheidungen dominieren die Trainingsdaten, sodass das Modell ohne Vorgabe aus diesem Zentrum hoher Wahrscheinlichkeit schöpft (Anthropic, 2025).

Das Frontend-Team von Anthropic beschreibt das Ergebnis ganz nüchtern. Soll ein Modell ohne Anleitung eine Landingpage bauen, hält es sich „fast immer an Inter-Schriften, violette Farbverläufe auf weißem Hintergrund und minimale Animationen“ (Anthropic, 2025). Das untergrabe die Markenidentität und mache KI-erstellte Oberflächen leicht erkennbar und leicht abzutun.

Die typischen Merkmale erkennt man leicht, wenn man sie kennt:

• Inter, Roboto oder Systemschriften überall, mit Schriftstärken, die sich zwischen Überschriften und Fließtext kaum unterscheiden
• Violette oder lilafarbene Farbverläufe und Überschriften mit Farbverlauf
• Ein zentrierter Hero-Bereich mit Pill-Badge, Überschrift, Unterzeile und zwei Buttons
• Drei identische Karten unter dem Hero, egal welcher Inhalt
• Überall dieselben abgerundeten Ecken und derselbe weiche graue Schatten
• Emojis oder generische Linien-Icons neben jedem Punkt

Dieselbe Untersuchung zeigt auch den Ausweg. Claude lässt sich gut steuern: Sagen Sie ihm, welche Standardwerte es meiden und was es stattdessen verwenden soll, und das Ergebnis wird sofort besser (Anthropic, 2025).

Anthropic hat diese Anleitung als Frontend-Design-Skill und als Claude-Code-Plugin veröffentlicht und weist darauf hin, dass Sie einen eigenen Skill rund um das Designsystem Ihres Unternehmens bauen können. Genau dieser Punkt zählt bei einer Unternehmenswebsite.

Allgemeine Ratschläge zu „interessanten Schriften“ führen zu einer anderen generischen Website. Ihr eigenes Designsystem führt zu Ihrer.

Beginnen Sie mit einem Designsystem, nicht mit einem Prompt

Ein Designsystem für einen KI-Build besteht aus benannten Entscheidungen, die Claude lesen kann: Farben, Schriften, Schriftgrößen, Abstände, Eckenradius und Breakpoints, jeweils mit einer festen Aufgabe. Als Design-Tokens in einer Datei festgehalten, werden sie zu den einzigen Werten, die die Website verwenden darf.

Der Unterschied zu einem Markenrichtlinien-PDF: Tokens sind maschinenlesbar. Ein PDF sagt, Ihre Akzentfarbe sei Orange. Eine Token-Datei sagt: brand.flame ist #df4e32 und wird für das Logo, Pfeile, aktive Filter und den Eingabefokus verwendet, für nichts sonst. Claude kann Letzterem exakt folgen, und ein Skript kann prüfen, ob es das getan hat.

Das enthält ein brauchbares Designsystem für einen Claude-Code-Build:

• Farb-Tokens mit klarer Aufgabe. Hintergrund, Text, Überschriften, abgeschwächter Text, Rahmen, eine Signalfarbe und die Themes (zum Beispiel ein dunkles und ein helles), die sie kombinieren.
• Typografie. Die Markenschriften als Dateien, die Sie lizenzrechtlich selbst hosten dürfen, eine Schriftskala mit deutlichen Größensprüngen und die Schriftstärken, die jede Ebene nutzt.
• Abstände, Radius und Breakpoints. Eine Abstandsskala, ein Radius pro Rolle (Buttons, Karten, Sektionen) und die Bildschirmbreiten, bei denen sich das Layout ändert.
• Komponenten mit jeweils einem Namen. Ein Button, eine Karte oder ein Hero heißt in der Designdatei, im Code und im CMS gleich, sodass niemand übersetzen muss.

Woher kommt das alles? Wenn Sie einen Designer oder eine Figma-Bibliothek haben, exportieren Sie die Tokens von dort.

Wenn Sie eine bestehende Website haben, die Ihnen gefällt, lassen sich die Tokens aus ihrem Stylesheet auslesen, so geschah es beim Relaunch von SaaS Hackers. Haben Sie weder das eine noch das andere, bezahlen Sie einen Designer für diesen Teil, bevor Sie irgendetwas bauen. Ein Tag Designentscheidungen ist günstiger als eine Website, die aussieht wie alle anderen.

Eine technische Entscheidung sorgt dafür, dass das System hält. Wenn Sie Tailwind CSS nutzen, importieren Sie nicht das Standard-Theme. Erzeugen Sie das Theme stattdessen aus Ihrer Token-Datei, sodass im Projekt nur Ihre Farben, Größen und Schriften existieren. Claude kann dann kein Standard-Violett wählen, das gar nicht vorhanden ist.

Wie halten Sie die Regeln für Claude schriftlich fest?

Claude Code liest zu Beginn jeder Sitzung eine Datei namens CLAUDE.md. Dort gehören die Regeln für das Projekt hinein. Eine Projekt-CLAUDE.md liegt im Repository und wird über die Versionsverwaltung mit allen geteilt, die daran arbeiten (Claude Code docs, 2026).

Anthropics Hinweise zum Schreiben dieser Datei sind praktisch. Halten Sie jede CLAUDE.md unter etwa 200 Zeilen, denn längere Dateien verbrauchen mehr Kontext und verringern, wie gut Claude ihnen folgt.

Formulieren Sie Anweisungen so konkret, dass sie sich prüfen lassen: „Run npm test before committing“ statt „test your changes“. Gruppieren Sie Regeln unter Überschriften und entfernen Sie solche, die sich widersprechen (Claude Code docs, 2026).

Sie müssen auch nicht bei null anfangen: Der Befehl /init erstellt aus Ihrer Codebasis den Entwurf einer Startdatei.

Für den Bau einer Website deckt eine funktionierende CLAUDE.md fünf Dinge ab:

1. Was Sie bauen und womit. Den Stack, das Hosting und den Speicherort der Inhalte.
2. Die Never-Liste. Dinge, die nicht passieren dürfen: eine Live-URL ändern, Secrets committen, ohne Rückfrage einen kostenpflichtigen Dienst oder ein Drittanbieter-Skript einbinden, in das falsche CMS-Projekt schreiben.
3. Standards. Keine Farben, Größen oder Schriften außerhalb der Tokens. Überall derselbe Komponentenname. Standardmäßig statische Ausgabe. WCAG 2.2 AA. Britisches oder US-Englisch.
4. Schreibregeln für jeden Text, den Claude ergänzt. Einfache Sprache, keine erfundenen Texte und ein Platzhalter, den niemand übersehen kann (die Wörter COPY NEEDED in Großbuchstaben plus eine Angabe, was fehlt), wo es noch keinen Text gibt.
5. Befehle. Wie Sie den Dev-Server, den Build und jede Prüfung starten. Anthropics Best Practices bezeichnen den Befehl, der Ihre Prüfungen ausführt, als nützlichste einzelne Zeile der Datei (Claude Code docs, 2026).

CLAUDE.md ist eine Orientierung, keine Durchsetzung. Claude behandelt die Datei als Kontext und kann entscheiden, dass eine Vorgabe nicht greift. Für alles, was jedes Mal geschehen muss, etwa den Formatter ausführen oder nie eine Secrets-Datei lesen, bietet Claude Code Hooks und Berechtigungsregeln, die das Tool selbst anwendet (Claude Code docs, 2026).

Legen Sie das ausführlichere Briefing in eine separate Spezifikationsdatei. Anthropic empfiehlt, Claude so lange Fragen an Sie stellen zu lassen, bis es die Spezifikation schreiben kann, diese als SPEC.md zu speichern und dann eine neue Sitzung zu starten, um darauf aufbauend zu entwickeln. So beginnt der Build mit einem sauberen Kontext und einer schriftlich festgehaltenen Definition of Done (Claude Code Docs, 2026). Für Marken- und Designregeln, die nur gelegentlich eine Rolle spielen, hält ein Skill sie aus dem Weg, bis sie gebraucht werden. Wie das funktioniert, erklärt unser Beitrag zu Claude Skills für Marketingteams.

In kleinen Phasen bauen, die ein Mensch freigibt

Eine mit Claude Code gebaute Website scheitert auf dieselbe Weise wie eine von einem Junior-Entwickler gebaute: zu viel auf einmal, und bis zum Schluss schaut niemand hin. Die Lösung ist ebenfalls dieselbe. Teilen Sie den Build in Phasen auf, prüfen Sie jede einzelne und beginnen Sie die nächste erst, wenn die vorherige freigegeben ist.

Eine Phasenfolge, die sich für eine Marketing-Website bewährt hat:

1. Einrichtung. Framework, Styling, CMS und Hosting sind verbunden, und eine leere Seite wird auf einen Vorschau-Link ausgeliefert.
2. Inhaltsmodell und Migration. CMS-Schemas, und bestehende Inhalte werden als Entwürfe übernommen.
3. Designsystem. Tokens, Schriften und alle Komponenten, dargestellt auf einer Katalogseite.
4. Templates und Seiten. Jeder Seitentyp wird aus den Komponenten gebaut und mit echten Inhalten befüllt.
5. SEO. Head-Tags, strukturierte Daten, Sitemap, Weiterleitungen und Abgleich mit der alten Website.
6. Veröffentlichung. Vorschauen, Redaktions-Workflow und alles, was die Website neu erstellt, sobald sich Inhalte ändern.

Jede Phase endet mit einem Pull Request und einem Vorschau-Link, den ein Mensch durchklicken kann. Der Pull Request hält fest, was gebaut wurde, was geprüft wurde und was dabei herauskam, welche Annahmen Claude getroffen hat und was noch offen ist. Unter dieser letzten Überschrift kommen ungeklärte Fragen zum Vorschein, statt stillschweigend geraten zu werden.

Warum ein Komponentenkatalog wichtig ist

Der Katalog ist eine Seite, die jede Komponente in jedem Zustand zeigt: jeden Button-Stil, jede Karte, den Header geöffnet und geschlossen, Formularfelder mit Fehlermeldungen, jeden Sektionsblock mit Beispielinhalten. Hier geben Sie das Erscheinungsbild frei, bevor ein Template es verwendet. Eine Karte einmal im Katalog zu korrigieren, ist weit günstiger, als den Fehler auf 200 Seiten zu entdecken. Nehmen Sie den Katalog nicht in die Sitemap auf und setzen Sie ihn auf noindex.

Betrachten Sie den Katalog nicht nur auf dem Desktop, sondern auch in Smartphone-Breite. Die meisten generisch wirkenden KI-Builds fallen zuerst auf dem Smartphone auseinander: zu kleine Schrift, zu enge Karten, sich überlappende Menüs.

Welche Prüfungen halten eine KI-gebaute Website auf Kurs?

Die Prüfungen verhindern, dass ein guter Anfang in einem generischen Ergebnis endet. Die Best Practices von Anthropic bringen es auf den Punkt: Claude hört auf, wenn die Arbeit fertig aussieht. Geben Sie ihm deshalb etwas, das mit bestanden oder nicht bestanden antwortet, dann kann es eigene Fehler beheben, bevor Sie sie sehen (Claude Code Docs, 2026).

Für eine Marketing-Website lohnt es sich, diese Prüfungen einzubauen. Lassen Sie den Build sie selbst ausführen, damit ein Fehler das Deployment stoppt, statt nur auf einer To-do-Liste zu landen.

• Tokens aktuell. Das generierte Stylesheet stimmt mit der Token-Datei überein, sodass niemand das eine ohne das andere geändert hat.
• Kontrast. Jede Text-, Formularfeld- und Fokus-Kombination in jedem Theme erfüllt WCAG 2.2 AA. Das bedeutet mindestens 4,5:1 für normalen Text und 3:1 für großen Text (W3C, 2023). Auch der Fokusrahmen und die Rahmen, die ein Bedienelement kennzeichnen, brauchen 3:1.
• Token-Lint. Ein Skript, das bei jeder Farbe, Größe oder Schrift im Code fehlschlägt, die kein Token ist: keine Hex-Codes, keine rgb(), keine in eine Komponente getippten Pixelgrößen, keine Schriftnamen.
• Komponentennamen. Jeder Sektionsblock im CMS hat eine Komponente mit demselben Namen, und umgekehrt.
• Barrierefreiheits-Scan. Ein automatisierter Scan wie axe für jeden Seitentyp sowie eine Tastaturprüfung: Lässt sich jedes Menü, jeder Filter und jedes Formular ohne Maus erreichen und bedienen?
• Geschwindigkeit. Lighthouse auf Mobilgeräten für die Startseite und die wichtigsten Templates, mehrfach ausgeführt. Was die Geschwindigkeitswerte messen, erklärt unser Beitrag zu Core Web Vitals.
• Layout in echten Breiten. Screenshots oder ein Overflow-Scan in Smartphone-, Tablet- und Desktop-Breite, um Text zu finden, der aus seinem Feld herausragt.

Verlangen Sie von Claude jedes Mal Belege: den ausgeführten Befehl und die Ausgabe. „Alle Prüfungen bestanden“ allein sagt wenig aus, und die Ausgabe zu lesen geht schneller, als sie selbst noch einmal auszuführen (Claude Code Docs, 2026).

Sehen Sie sich die Seiten anschließend mit eigenen Augen an. Automatisierte Prüfungen erfassen, was messbar ist. Sie können Ihnen aber nicht sagen, ob eine Seite wie ein Template aussieht.

Wie ersetzen Sie eine bestehende Website, ohne Suchtraffic zu verlieren?

Eine Live-Website zu ersetzen ist eine Migration, und das Risiko liegt weniger in schlechter Optik als im Verlust von Rankings. Davor schützt diese Regel: Jede URL, die auf der alten Website existiert, behält auf der neuen exakt dieselbe Adresse oder erhält eine permanente Weiterleitung auf die passende Seite.

Claude Code eignet sich gut für das Prüfen, weil es repetitiv und exakt ist. Richten Sie bei einem Relaunch vor der Umstellung drei Prüfungen ein:

• Routenprüfung: Jede Adresse der alten Sitemap liefert in der neuen Vorschau einen 200 zurück, und eine unbekannte Adresse liefert einen 404.
• Paritätsprüfung: Vergleichen Sie für jede Adresse Titel, Meta-Beschreibung, Canonical, H1 und strukturierte Daten mit der Live-Seite und lassen Sie die Prüfung bei allem fehlschlagen, was verloren gegangen ist.
• Weiterleitungsprüfung: Jede Weiterleitung der alten Plattform wird neu angelegt, Ketten werden aufgelöst, und keine Weiterleitung führt auf eine Seite, die erneut weiterleitet.

Lassen Sie Claude keinen Slug ändern, „um aufzuräumen“. Nehmen Sie „Ändere niemals eine URL, die auf der Live-Website existiert“ in die Never-Liste auf. Das größere Bild behandelt unser SEO-Strategie-Leitfaden. Ist die Website groß oder der Traffic besonders wichtig, kann eine Agentur aus unserer Liste der SEO-Migrationsagenturen den Migrationsplan verantworten, während Claude den Build übernimmt.

Aus der Praxis: Wie SaaS Hackers mit Claude Code neu aufgebaut wurde

SaaS Hackers (betrieben von Team 4) ist im November 2026 von Webflow auf Astro, Tailwind CSS, TypeScript, Sanity und Netlify umgezogen, den Build hat Claude Code übernommen. Das Briefing war beim Erscheinungsbild eindeutig: das aktuelle Design neu aufbauen, kein Redesign. Es gab weder eine Figma-Datei noch ein Designsystem, daher wurde das Designsystem aus der Live-Website erstellt.

Das bestimmte das Vorgehen. Farben, Schriften, Abstände und Eckenradius wurden aus dem Live-Stylesheet in eine Token-Datei übernommen, die am Ende 26 Farb-Tokens und drei Themes (Dark, Black und Light) enthielt. Die Display-Schrift der Marke, Heming, ist für das Self-Hosting lizenziert, und Inter ist Open Source, daher wurden beide selbst gehostet.

Das Standard-Theme von Tailwind wurde nicht importiert, sodass die Tokens die einzigen verfügbaren Werte waren. Header, Footer, Karten, Teile der Expertenprofile, Formularfelder, Beitragstext und 14 Sektionsblöcke wurden mit passenden CMS-Blöcken gebaut und in einem Komponentenkatalog gezeigt.

Die vier Design-Prüfungen (Tokens, Kontrast, Token-Lint und Komponentennamen) laufen zu Beginn jedes Builds und stoppen ihn, sobald eine fehlschlägt. Die Komponenten wurden in Smartphone- und Desktop-Breite freigegeben, bevor ein Template sie verwendete.

Die eigenen Projektaufzeichnungen zeigen, wie gut es funktioniert hat:

• axe fand bei Fertigstellung der Templates 0 Verstöße auf 13 Seiten.
• Alle 409 relevanten Adressen lieferten in derselben Phase in der Vorschau einen 200 zurück.
• Alle 409 Adressen schnitten bei der Paritätsprüfung (Titel, Beschreibung, Canonical, H1 und Schema) mindestens so gut ab wie die Live-Seiten auf Webflow, ohne Verluste.
• Lighthouse mobil in der Produktion, jeweils drei Durchläufe für die englische und die deutsche Startseite, einen Beitrag und ein Expertenprofil, ergab 99 bis 100 bei der Performance und 100 bei Barrierefreiheit und Best Practices.
• Ein Overflow-Scan von 11 Seitentypen in 7 Sprachen bei 4 Bildschirmbreiten ergab keine Probleme.

Den Unterschied machte etwas Einfaches. Claude musste nie eine Farbe oder Schrift wählen, denn das hatte die Token-Datei bereits getan. Und ein Mensch prüfte jede Phase, bevor die nächste begann, sodass Probleme im Katalog statt auf Live-Seiten auffielen. Schneller als ein Team war Claude bei der repetitiven Arbeit: Inhaltsmigration, die 134 bis zum Launch eingerichteten Weiterleitungen und das erneute Ausführen derselben Prüfungen nach jeder Änderung. Wie die Website im Alltag läuft, mit ihren Agenten und Leitplanken, steht in unserem Leitfaden zum Claude-Code-Tech-Stack für eine agentische Website.

Häufige Fehler und wie Sie sie vermeiden

Die meisten gescheiterten KI-Website-Builds scheitern an einem von wenigen Gründen. Für jeden gibt es eine einfache Lösung.

Mit „Bau mir eine Startseite“ anfangen. Claude füllt jede Lücke mit einem Standardwert, und die Startseite prägt das Erscheinungsbild von allem, was danach kommt. Schreiben Sie zuerst das Designsystem und die CLAUDE.md, bauen Sie dann die Komponenten und erst danach die Seiten.

Die Marke mit Adjektiven beschreiben. „Mutig, modern, vertrauenswürdig“ ist nichts, womit ein Modell etwas anfangen kann. Geben Sie ihm Tokens, Schriftdateien und einen Screenshot einer Seite, die Ihnen gefällt. Die Docs von Anthropic empfehlen, den Design-Screenshot direkt in den Prompt einzufügen.

Alles in einer Sitzung bauen. In langen Sitzungen gehen frühe Entscheidungen verloren. Arbeiten Sie in Phasen, starten Sie neue Sitzungen auf Basis der Spezifikation und halten Sie jede Änderung so klein, dass sie sich prüfen lässt.

„Fertig“ einfach glauben. Claude meldet, was es für richtig hält. Lassen Sie den Build die Prüfungen ausführen, fordern Sie die Ausgabe an und sehen Sie sich die Vorschau in Smartphone-Breite selbst an, bevor Sie etwas freigeben.

Texte aus dem Nichts entstehen lassen. Ein KI-Build schreibt plausible Headlines und Kundenstimmen, um Platz zu füllen. Verbieten Sie erfundene Texte in der CLAUDE.md und nutzen Sie sichtbare Platzhalter, damit nichts Erfundenes auf die Live-Seite gelangt. Wie Sie die echten Texte schreiben, erklärt unser Leitfaden zum Einsatz von Claude für Copywriting.

Wann sollten Sie einen Designer oder eine Agentur hinzuziehen?

Claude Code ersetzt einen Großteil der Build-Zeit. Gestalterisches Urteilsvermögen ersetzt es nicht. Holen Sie einen Designer dazu, wenn Sie kein Designsystem haben, wenn die Marke selbst überarbeitet werden muss oder wenn die Website der wichtigste Maßstab ist, an dem Käufer Sie messen, und „ganz okay“ nicht reicht.

Sinnvoll ist eine Aufteilung: Sie bezahlen einen Designer für das System und die wichtigsten Seitendesigns und lassen Claude Code anschließend unter den oben genannten Prüfungen danach bauen. Ein Designer liefert Ihnen außerdem einen Vergleichsmaßstab: Ein Mockup, an dem sich Claude prüfen lässt, schlägt jede Beschreibung. In unserer Liste der Webdesigner für B2B-SaaS-Marken finden Sie Freelancer, die diesen Teil übernehmen können.

Holen Sie eine Agentur dazu, wenn jemand das Ganze verantworten soll: Strategie, Design, Build, Migration und einen Ansprechpartner, der haftet, wenn etwas kaputtgeht. Fragen Sie, wie die Agentur KI in ihrem Build-Prozess einsetzt und welche Prüfungen laufen, bevor etwas live geht. Wenn Sie das ganze Projekt lieber abgeben möchten, vergleichen Sie die besten Webdesign-Agenturen für B2B-SaaS, bevor Sie jemanden briefen.

Über SaaS Hackers

SaaS Hackers ist eine Community von B2B-SaaS-Spezialisten, die praxisnahe Erkenntnisse teilen, gegründet von den Machern hinter dem Wachstum. Sie veröffentlicht praktische Leitfäden, Vorlagen und ein handverlesenes Verzeichnis von Agenturen und Experten mit nachweislicher Erfahrung im digitalen B2B-SaaS-Marketing. SaaS Hackers wird von Team 4 betrieben, und diese Website wurde mit Claude Code nach dem in diesem Leitfaden beschriebenen Vorgehen neu aufgebaut.