Website-Builder sind tot. Es lebe (endlich wieder) die statische Website

Es fängt immer harmlos an. Ihr wollt nur eine Seite, die schnell lädt, gut gefunden wird und nicht jeden Monat Geld kostet, bloß damit sie weiterläuft. Dann zeigt Lighthouse orange, das Template kann das eine Element nicht, das Ihr braucht, das SEO-Plugin will ein Update, das Cookie-Tool ein neues Pflichtfeld – und am Monatsende kommt die Rechnung für ein Abo, das Ihr vor allem dafür bezahlt, dass Ihr nicht kündigen könnt, ohne die Seite zu verlieren.

Ich baue Websites seit 1998 – nicht die ganze Zeit als Profi, aber durchgehend als jemand, der Dinge ins Netz stellt. Angefangen habe ich mit Dreamweaver, später kamen eigenes HTML und CSS dazu – und anfangs lag alles stets unter einer .de.vu-Adresse. Wer die noch kennt, weiß, wie lange das her ist. Während des Studiums habe ich mit Website-Bau Geld verdient, viel davon mit WordPress-Templates, die ich von Hand gebaut habe. Seit ich als Produktmensch arbeite, wollte meine teils mittelmäßige Codequalität allerdings niemand mehr sehen – bis heute. Ich kann Websites also von Hand bauen – und ja, ich weiß, wie es klingt, wenn ausgerechnet ich gleich WordPress für erledigt erkläre.

Trotzdem lief meine Seite zuletzt ein paar Jahre in einem der großen Baukästen – denn der Baukasten war immer eine Arbeitserleichterung, wenn der Fokus woanders liegen muss. Das ist noch immer das ehrlichste Argument für ihn. Und genau dieses Argument ist gerade dabei, sich aufzulösen.

Seit dem 30. August 2026 läuft produktkraft.com anders: als statische Website auf Cloudflare Pages, die Inhalte als Markdown-Dateien in einem Git-Repository, gebaut und gepflegt mit einem KI-Agent in der IDE. Denselben Stack habe ich kurz vorher für ganzheit, die Dokumentationsplattform für PsychotherapeutInnen, aufgesetzt und an andere GründerInnen weitergegeben.

Meine These vorweg, damit niemand bis zum Ende lesen muss, um sich zu ärgern: Squarespace, Wix, Webflow, WordPress – können alle weg. Nicht, weil sie schlecht gebaut wären, sondern weil das Problem, das sie lösen, nicht mehr existiert.

Das Problem, das Baukästen gelöst haben, gibt es nicht mehr

Baukästen und CMS haben jahrzehntelang eine einzige Frage beantwortet: Wie bekommt jemand, der kein HTML schreibt, trotzdem eine Website ins Netz? Die Antwort war eine Oberfläche. Drag and Drop, Textblöcke, Templates, ein Admin-Bereich mit Login. Für diese Oberfläche bezahlt Ihr – im Abo, in Plugin-Pflege, in Ladezeit, in Abhängigkeit.

Diese Frage hat inzwischen eine bessere Antwort. Ein KI-Agent schreibt das HTML, und zwar schneller, als Ihr im Baukasten das richtige Template findet. Was Ihr selbst noch braucht, ist nicht mehr eine Oberfläche zum Klicken, sondern eine Sprache, um zu sagen, was Ihr wollt – und die könnt Ihr schon. Damit wird die Oberfläche vom Werkzeug zum Hindernis: Sie steht zwischen Euch und dem, was technisch möglich wäre.

Hier beschreibe ich, wie der Stack aussieht, der an ihre Stelle tritt – entlang der Dinge, für die Ihr einen Baukasten eigentlich bezahlt: Preis, Performance, Technik, SEO und Flexibilität. Und am Ende, für wen er trotzdem nicht passt.

Was „statisch“ eigentlich heißt

Eine statische Website ist eine, die nicht erst beim Aufruf zusammengebaut wird. Ein Static Site Generator – bei mir Astro – nimmt einmal alle Inhalte und Vorlagen und erzeugt daraus fertige HTML-Dateien. Die liegen dann auf einem Server und werden ausgeliefert, wie sie sind. Keine Datenbank, kein Login-Bereich, kein Plugin, das nachts eine Sicherheitslücke bekommt.

Neu ist daran nichts. Statische Seiten sind älter als jeder Baukasten – meine Dreamweaver-Seiten auf .de.vu waren nichts anderes –, und Static Site Generators wie Jekyll gibt es seit 2008. Nur hat sich der Aufwand für die meisten nie gelohnt: Templates schreiben, Build-Werkzeuge konfigurieren, Git lernen, ein Deployment einrichten – und für jede neue Seite wieder ran an den Code. Das war ein Werkzeug für EntwicklerInnen, nicht für GründerInnen, deren Fokus auf dem Produkt liegen muss. Genau diesen Aufwand übernimmt jetzt der Agent. Die Technik ist dieselbe geblieben; verschoben hat sich die Rechnung.

Cloudflare Pages übernimmt den Rest: Das Repository ist mit Cloudflare verbunden, und jeder Push nach main stößt einen Build an. Ein paar Minuten später ist die neue Fassung live, verteilt über Cloudflares Netz.

Cloudflare ist dabei nicht alternativlos. Netlify, Vercel und GitHub Pages funktionieren nach demselben Prinzip, und eine statische Seite zieht zwischen ihnen in einer Stunde um. Ein Blick ins Kleingedruckte lohnt sich trotzdem: Vercels kostenloser Hobby-Tarif ist laut eigenen Richtlinien auf private, nicht-kommerzielle Nutzung beschränkt – eine Firmenwebsite gehört dort in den Pro-Tarif. Und GitHub Pages ist nach GitHubs Dokumentation ausdrücklich nicht dafür gedacht, ein Online-Business, einen Shop oder ein SaaS-Angebot zu betreiben. Für ein Startup schrumpft die Liste der kostenlosen Optionen damit schneller, als man denkt.

Die Kehrseite gehört gleich dazu: Ein Push nach main ist live. Es gibt keinen Entwurfsmodus und keine Zeitplanung wie im Baukasten. In der Praxis vermisse ich beides nicht, denn die Vorschau ist der eigene Rechner. Ihr startet die Seite lokal, sie läuft unter localhost, und jede Änderung, die der Agent macht, steht Sekunden später im Browser. Iteriert wird dort, so lange, bis es passt – erst dann wird gepusht.

Eine Staging-Umgebung braucht Ihr nur, wenn nicht-technische Menschen mitschauen sollen. Wer technisch ist, zieht sich einfach den Branch und schaut ihn sich auf dem eigenen localhost an. Bei ganzheit landet deshalb jeder Branch außer main zusätzlich auf einer Staging-Adresse hinter Cloudflare Access – sodass auch Menschen ohne IDE einen Link bekommen, den nur das Team öffnen kann.

Preis: Null ist eine schöne Zahl

Fangen wir mit dem Argument an, das am schnellsten zieht. Die gängigen Baukästen und gehosteten CMS liegen in ihren üblichen Tarifen zwischen ein paar und rund 40 Euro oder Dollar im Monat, bei jährlicher Zahlung. Wer monatlich zahlt, zahlt mehr, und die großen Tarife gehen bis weit über 100 im Monat (Stand: Preisseiten der großen Anbieter am 16. Oktober 2026).

Bei 20 € im Monat landet Ihr nach fünf Jahren bei 1.200 €. Das ist für sich kein Drama. Es ist nur Geld für eine Oberfläche, die Ihr nicht mehr braucht – und die Domain und das eine Plugin, ohne das es dann doch nicht geht, kommen oft noch obendrauf.

Cloudflare Pages kostet im Free-Plan nichts. Enthalten sind laut Cloudflare-Doku 500 Builds im Monat – mehr als sechzehn Veröffentlichungen am Tag. Ich habe es noch nicht geschafft, dagegen zu laufen. Für große Dateien gibt es R2, Cloudflares Objektspeicher: zehn Gigabyte im Monat frei, und der Abruf kostet gar nichts. Meine Podcastfolgen liegen dort, rund drei Gigabyte Audio, und jeder Download ist umsonst.

Was bleibt, sind die Domain und das Abo für den KI-Agent. Das habt Ihr im Zweifel ohnehin, und es baut Euch nebenbei noch ganz andere Dinge als eine Website. Und anders als der Baukasten muss es nicht durchlaufen: Die Seite bleibt online, auch wenn das Abo pausiert. Im Zweifel braucht Ihr den Agent nur für den Monat, in dem Ihr baut – und dann wieder, wenn sich etwas ändern soll.

Performance: kein Gefühl, sondern ein roter Build

Fertiges HTML aus einem weltweiten Netz ist schwer zu schlagen. Lighthouse misst für die Startseite von produktkraft.com in der mobilen Ansicht 92 Punkte Performance und je 100 für Accessibility, Best Practices und SEO (gemessen am 16.10.2026). Zwischendurch steht auch bei Performance oft die 100 – und dann regnet es in Lighthouse Konfetti. Das habe ich in meiner ganzen Karriere vorher noch nie gesehen.

Spannender als die Zahl ist, dass sie nicht mehr zufällig ist. Bei jedem Build läuft Lighthouse gegen vier Seitentypen – Startseite, Podcastübersicht, eine Episodenseite mit 88 Kilobyte Transkript und einen Blogartikel. Fällt eine davon unter 90 Punkte Performance oder unter 100 bei Accessibility, wird die Prüfung rot – und ich pushe nicht. Im Baukasten erfahrt Ihr von einer langsamen Seite, wenn das Ranking schon weg ist. Hier erfahrt Ihr es, bevor sie online ist.

Der Check hat mich gleich zu Beginn erwischt: Lokal lieferte er das Stylesheet unkomprimiert aus, 59 statt 19 Kilobyte, und die Bewertung fiel von 98 auf 91. In Produktion komprimiert Cloudflare – also komprimiert jetzt auch der Test. Das ist die Sorte Detail, um die sich in einem Baukasten niemand kümmert, weil niemand sie sieht.

Accessibility gehört für mich hierher, nicht in die Rechtsabteilung. Das Barrierefreiheitsstärkungsgesetz gilt seit Juni 2025, Kleinstunternehmen mit Dienstleistungen sind ausgenommen. Viele Startups müssten also gar nicht. Ich finde trotzdem: Let's be an ally. Wenn das HTML Euch gehört, sind Alt-Texte, eine saubere Überschriftenhierarchie und ausreichende Kontraste keine Frage des Templates, sondern eine Zeile in Euren Regeln – und eine Prüfung, die rot wird, wenn sie fehlt.

Technische Exzellenz als Standard, nicht als Projekt

Ein Befehl, pnpm verify, prüft vor jedem Deploy elf Dinge: ob der Build durchläuft, ob die Podcast- und Blog-Feeds gültig sind, ob alle Audiodateien erreichbar sind, ob jede jemals veröffentlichte URL noch funktioniert, ob die Vorschaubilder für Social Media stimmen, ob Titel, Descriptions und strukturierte Daten vollständig sind, ob ein interner Link ins Leere führt, ob auf dem Handy etwas aus dem Bild läuft – und eben die Performance. Keiner dieser Checks ist Raketenwissenschaft. Jeder ist die Antwort auf die Frage, was nie wieder passieren darf.

Wie viel Kontrolle das bringt, hat der Umzug gezeigt. Podcast-Apps fragen meinen Feed seit Jahren unter einer Adresse mit Query-String ab, so wie mein alter Baukasten sie erzeugt hatte. Statt eines Feed-Umzugs mit Weiterleitung und Bangen liefert jetzt eine kleine Cloudflare-Function genau diese Adresse weiter aus. Für Apple Podcasts und Spotify hat sich schlicht nichts geändert.

Dazu gehört auch das Thema, für das andere eine Consent-Management-Plattform vom Schlage OneTrust lizenzieren. Hier muss ich ehrlich sein, denn das Versprechen „ohne Cookie-Banner“ stimmt so nicht. Nach § 25 Abs. 2 TDDDG braucht es keine Einwilligung, solange nur technisch notwendige Cookies gesetzt werden. Sobald Google Analytics, ein Pixel oder ein eingebettetes Video ins Spiel kommt, ist der Banner wieder da – egal, wie die Seite gebaut ist.

Was der Stack ändert: Der Banner ist kein fremdes Skript mehr, das Ihr lizenziert und dessen Verhalten Ihr nur halb versteht, sondern ein Stück Eurer eigenen Seite. Auf produktkraft.com zählt Cloudflare Web Analytics die Besuche ohne Cookies; Google Analytics lädt erst nach Zustimmung, und Google bekommt vorher über Consent Mode ein „denied“ signalisiert. Und der Zwang, den Banner selbst zu bauen, stellt die richtige Frage: Braucht Ihr das Tracking überhaupt?

Dahinter steckt ein größerer Vorteil: Wer weniger Daten verarbeitet, hat weniger Datenschutz zu erklären. Eine statische Seite hat keine Datenbank, keine Nutzerkonten, kein Formular-Backend und keine Plattform, die nebenbei eigene Skripte und Dienste mitbringt. Was übrig bleibt, passt bei mir in vier Spiegelstriche ganz oben in der Datenschutzerklärung: Der Hoster sieht technische Verbindungsdaten, eine Reichweitenmessung läuft ohne Cookies, Google Analytics nur nach Zustimmung – und wer mir schreibt, dessen Nachricht lese ich. Keinen Shop, keinen Newsletter, kein Kontaktformular. Eine Datenschutzerklärung, die man tatsächlich lesen kann, ist auch eine Form von Respekt vor den Menschen, die Eure Seite besuchen.

Dass Eigenbau auch eigene Fehler bedeutet, hat ganzheit gezeigt. Als wir Google Analytics dazugenommen haben, hing die Mess-ID an einer Umgebungsvariablen im Cloudflare-Dashboard. Dort fehlte sie – und die Seite lief ohne Messung und ohne Cookie-Banner. Kein Fehler, keine Warnung, nichts, was man der Seite angesehen hätte. Ein kurzer Schluckauf, der sofort aufgefallen ist, aber einer, der lehrreich war: Seitdem steht die ID im Code, und eine Prüfung schaut nach, ob der Banner kommt. Lektion gelernt, Prüfung geschrieben.

SEO: Die Seite gehört Euch, bis in den Quelltext

Mein alter Baukasten hat bei 15 von 21 meiner Podcastfolgen die URL selbst aus dem Titel erzeugt und dabei die Umlaute ersatzlos verschluckt. Wer es nachprüfen will: Meine Folge über AI-First-Gründungen mit Henrik Roth heißt in der Adresse bis heute „grnden“. Weil eine geänderte URL jeden Link bricht, bleibt das auch so. Neue Adressen setze ich jetzt selbst, kurz und mit Keyword vorn.

Dasselbe gilt für alles, was Suchmaschinen und Sprachmodelle lesen, Menschen aber nie sehen – allen voran Schema-Markup. Im Baukasten bekommt Ihr davon, was das Template mitbringt, und meistens ist das ein generisches „WebPage“. Wenn das HTML Euch gehört, ist strukturiertes JSON-LD nach Schema.org eine Anweisung an den Agent, und zwar so genau, wie Ihr wollt. Auf produktkraft.com ist die Startseite als Person und ProfessionalService ausgezeichnet, jede Podcastfolge als PodcastEpisode mit AudioObject und ihren Kapitelmarken als Clip, jeder Artikel als BlogPosting – bei Rezensionen mit dem besprochenen Book, bei Essays mit den zitierten Quellen als citation. Dazu überall eine BreadcrumbList. Eine Prüfung stellt bei jedem Build sicher, dass jeder Seitentyp seine Auszeichnung trägt, das JSON parst und jeder Verweis darin ein Ziel hat – denn strukturierte Daten scheitern leise. Die Sitemap nimmt das Änderungsdatum aus dem Frontmatter, nicht aus dem Zeitpunkt des letzten Builds. Und es gibt eine llms.txt, eine Kurzfassung der ganzen Seite für Sprachmodelle. Wie sehr es inzwischen darauf ankommt, in LLMs gefunden zu werden, war genau das Thema der Folge mit Henrik.

Im Baukasten ist so etwas ein Feature, auf das Ihr wartet. Hier ist es ein Satz an den Agent.

Flexibilität: Wenn das Template nicht mehr nein sagt

Der stillste Vorteil ist vielleicht der größte: Es gibt keine Grenze mehr, die ein Template-Hersteller für Euch gezogen hat. Bei ganzheit entstehen aus denselben Texten, die auf der ganzheit-Website stehen, inzwischen auch A4-Druckstücke für PatientInnen und Coachees – mit einem Befehl. In einem Baukasten wäre das ein zweites Werkzeug, ein zweiter Datenbestand und ein zweiter Ort, an dem Texte veralten.

Dazu kommt die Unabhängigkeit. Die Inhalte sind Textdateien, die Seite ist ein Ordner voller HTML. Wenn Cloudflare morgen die Preise verdreifacht, zieht das Ganze an einem Nachmittag zu einem anderen Hoster um. Bei einem Baukasten exportiert Ihr bestenfalls ein XML und schaut dann, was davon übrig ist. Ich spreche aus Erfahrung: Für meinen Auszug habe ich ein eigenes Migrationsskript gebraucht. Ein Anbieter, der Euch den Umzug schwer macht, verkauft Euch keine Website, sondern einen Mietvertrag.

Und die Inhalte selbst? Dass sich eine Änderung über alle Seiten hinweg in einem einzigen, prüfbaren Commit erledigen lässt, ist für mich der eigentliche Grund, nicht zurückzuwollen. Dem widme ich nächste Woche einen eigenen Artikel.

Ein Seed-Markdown zum Nachbauen

Wie sieht das in der Praxis aus? Die meisten fangen nicht bei null an, sondern haben schon eine Seite – im Baukasten, bei einer Agentur, auf WordPress. Deshalb hier zwei Wege: die Migration einer bestehenden Seite in den Stack, den ich oben beschrieben habe, und den Neubau von Grund auf. Beide sind bewusst allgemein gehalten – nicht meine echten Dateien, sondern das, womit Ihr anfangen könntet.

Gemeinsam ist beiden die Anweisung für den Agent, etwa AGENTS.md im Wurzelverzeichnis – Codex liest sie unter diesem Namen, Claude Code als CLAUDE.md:

# Website der Beispiel GmbH

Statische Seite mit Astro, gehostet auf Cloudflare Pages.
Ein Push nach `main` ist live.

## Regeln
- Inhalte stehen in `content/`, nie im Code.
- Jede Seite hat `titel`, `slug`, `seo_titel` (≤ 60 Zeichen)
  und `meta_description` (140–160 Zeichen).
- Jedes Bild hat einen Alt-Text. Überschriften nie tiefer als H3.
- Slugs veröffentlichter Seiten werden nie geändert.
- Kein Skript von Dritten ohne Rückfrage.
- Vor jedem Push: `pnpm verify` muss grün sein.

## Marke
- Farben, Schriften und Tonalität: siehe `marke.md`.

Wir ziehen die Website von <FIRMA> von <BAUKASTEN, z. B. Wix> in einen
statischen Stack um: Astro, Inhalte als Markdown in Git, Hosting auf
Cloudflare Pages. Die bestehende Seite liegt unter <https://www.eure-domain.de>.

Stehen in diesem Prompt noch Platzhalter in spitzen Klammern, frag
nach, bevor Du anfängst. Arbeite dann in dieser Reihenfolge und halte
nach jedem Schritt an, damit ich prüfen kann:

1. Bestandsaufnahme: Frag mich nach den Besonderheiten der Seite,
   bevor Du etwas baust – RSS-Feeds, Podcast-Feed, Newsletter-
   Anbindung, Formulare, Shop, eingebettete Dienste, Mehrsprachigkeit.
   Halte sie in BESONDERHEITEN.md fest. Feeds behalten ihre Adresse
   und die Kennungen ihrer Einträge, sonst sehen Abonnenten alles neu.
2. Sichern: Lies die Sitemap der bestehenden Seite (meist
   /sitemap.xml) und schreib jede URL nach fixtures/live-urls.txt.
   Das ist der eingefrorene Altstand – er wird nie wieder geändert.
3. Inhalte holen: Übernimm alle Seiten und Artikel als Markdown nach
   content/, mit Frontmatter (titel, slug, seo_titel, meta_description).
   Kein Wort umformulieren.
4. Assets und Schriften: Lade alle Assets der Live-Seite herunter und
   leg sie ins Repository – Bilder in Originalgröße, PDFs und andere
   Downloads, Videos, Favicons, Vorschaubilder für Social Media. Dazu
   alle Schriftarten als Dateien, lokal eingebunden statt über ein
   fremdes CDN. Prüf bei jeder Schrift, ob die Lizenz das Selbsthosten
   erlaubt, und frag nach, wenn nicht. Nichts darf am Ende noch von der
   alten Domain geladen werden – schreib dafür eine Prüfung.
5. Gestaltung: Bau das Layout der bestehenden Seite nach – Farben,
   Schriften, Abstände. Danach zwei Korrekturschleifen gegen die
   Live-Seite: Screenshots beider Fassungen in denselben Breiten
   (Handy, Tablet, Desktop) nebeneinander, Abweichungen als Liste,
   beheben, erneut vergleichen.
6. URLs halten: Jede URL aus fixtures/live-urls.txt führt auf eine
   Seite oder per 301 weiter. Schreib dafür ein Prüfskript.
7. Accessibility: Alt-Texte für alle Bilder, saubere
   Überschriftenhierarchie, ausreichende Kontraste, vollständig per
   Tastatur bedienbar, Animationen respektieren reduzierte Bewegung.
8. Prüfkette: pnpm verify = Build, URL-Check, interne Links,
   SEO-Felder und Lighthouse gegen feste Schwellen (Performance ≥ 90,
   Accessibility 100, Best Practices ≥ 95, SEO 100). Erst wenn alles
   grün ist, ziehen wir die Domain um.

---
titel: "Leistungen"
slug: leistungen
seo_titel: "Leistungen: Was die Beispiel GmbH für Euch tut"
meta_description: "Drei Angebote, ein Ziel: …"
---

## Was wir machen

Ein Absatz in normalem Deutsch. Keine Shortcodes, kein HTML.

## Wie die Zusammenarbeit startet

Mit einem Kennenlernen. [Termin vereinbaren](/kontakt)

Wie schnell das geht? Der komplette Nachbau von produktkraft.com und von ganzheit war jeweils in ein bis zwei Arbeitstagen erledigt. Bei produktkraft.com standen am ersten Tag das Gerüst mit Podcast, Blog und beiden Feeds; bei ganzheit waren es Designsystem, Startseite, alle Unterseiten und der Blog. Und das waren keine Visitenkarten. produktkraft.com trägt einen Podcast mit über zwanzig Folgen, eigenem RSS-Feed für Apple Podcasts und Spotify, Player, Kapitelmarken und vollständigen Transkripten. ganzheit hat aufwändige Animationen – eine Audiowelle, die beim Hereinscrollen ausschlägt, Dokumente, auf denen die Zeilen unter ihren Überschriften wachsen, als würden sie gerade geschrieben –, und die funktionieren auch auf dem Handy. Wer in den Systemeinstellungen reduzierte Bewegung eingestellt hat, bekommt sie fertig und ruhig angezeigt.

Zugegeben: Ich weiß, was ich tue, und ich wusste vorher, wie beide Seiten aussehen sollen. Wer das zum ersten Mal macht, braucht etwas länger. Oder meldet sich bei mir: Kennenlern-Termin buchen. 🙃 Aber es muss ja nicht gleich ein Profi sein – die Seed-Dateien oben sind genau dafür da, es selbst zu versuchen.

Die AGENTS.md wächst dann mit. Jeder Fehler, den der Agent zweimal macht, wird eine Regel. Jede Panne wie die mit der Mess-ID wird ein Absatz – und eine Prüfung –, damit sie nicht zurückkommt.

Die Barriere, durch die man durch muss

Jetzt der unbequeme Teil. Damit das gut funktioniert, braucht Ihr drei Dinge, die nach Entwicklerwerkzeug klingen, weil sie welche sind: eine IDE, einen KI-Agent darin und Git.

Ich arbeite mit VS Code und Claude Code; Toni, der Gründer von Ocean Material, macht es mit VS Code und Codex. Ob der Agent im Terminal, in der IDE oder im Browser läuft, ist fast egal. Wichtig ist die IDE drumherum, denn sie ist der Ort, an dem Ihr seht, was der Agent tut: welche Dateien er anfasst, was sich im Diff ändert, ob der Build durchläuft. Ein Agent, dem Ihr nur im Chat zuschaut, ist ein Agent, dem Ihr blind vertraut. Es ist übrigens dieselbe Logik, mit der ich auch KI-Produkte baue – welche Werkzeuge es dafür wirklich braucht, steht in meinem Artikel über den Generative AI Tech Stack.

Git ist die zweite Hürde, und ich will sie nicht kleinreden. Commit, Branch, Push, Merge-Konflikt – das sind Begriffe, die nicht-technische GründerInnen in der ersten Woche fluchen lassen. Die gute Nachricht: Den größten Teil davon erledigt inzwischen der Agent, wenn Ihr ihn darum bittet. Die schlechte: Verstehen solltet Ihr trotzdem, was gerade passiert, sonst bleibt Ihr bei der ersten Abweichung stecken.

Meine Erfahrung mit den Foundern, denen ich den Stack zur Verfügung gestellt habe, ist trotzdem durchweg gut: Sie kommen damit klar und kommen zu Ergebnissen. Ocean Material ist dafür ein sichtbares Beispiel – eine Seite, die nicht von mir gebaut wurde, sondern von Toni selbst, mit Codex in VS Code. Vorher war die Website von Ocean Material ein ewig langes Projekt: eine WordPress-Basis, viele Dienstleister und endlose Zeit in Abstimmungen – Zeit, die man als Startup schlicht nicht hat. Heute versteht Codex die Ansagen schneller als jede Agenturschleife und setzt sie in Minuten um.

Und wer jetzt denkt, das sei ein Stack für kleine Seiten: Gerade steht die Website eines meiner Kunden kurz vor dem Umzug in genau diese Architektur – eine Seite mit vielen Millionen Aufrufen im Monat. Fertiges HTML aus einem weltweiten Netz ist es egal, wie viele Menschen gleichzeitig vorbeischauen.

Wer tiefer in die Frage einsteigen will, wie weit man mit KI-Programmierung ohne Engineering-Hintergrund kommt, findet in meinem Gespräch über Vibe-Coding, No-Code und Produktarbeit mit Hendrik Hemken eine gute Ergänzung.

Public Service Announcement: Der Agent nimmt Euch den Geschmack nicht ab

Bei aller Begeisterung: Dieser Stack funktioniert gut, wenn Ihr wisst, was Ihr wollt. Er funktioniert schlecht, wenn Ihr hofft, dass er es Euch sagt.

Alle drei Seiten, die ich hier erwähnt habe – ganzheit, produktkraft.com und Ocean Material –, hatten vorher schon eine Marke. Farben, Schriften, Tonalität, Bildsprache: Das alles war da, bevor der erste Prompt geschrieben wurde. Der Agent hat es umgesetzt, nicht erfunden. Bei ganzheit habe ich das Design gegen die Screens der App abgeglichen, nicht gegen eine Idee des Modells davon, wie eine Gesundheits-App aussehen sollte.

Wer dagegen mit „Bau mir eine schöne Website für mein Startup“ beginnt, bekommt eine Website, die aussieht wie alle anderen, die mit diesem Satz begonnen wurden. Großzügiger Weißraum, ein Farbverlauf, drei Feature-Kacheln mit Icons. Technisch sauber, schnell, barrierearm – und völlig austauschbar. Sprachmodelle sind sehr gut darin, den Durchschnitt zu treffen. Eine Marke ist aber gerade die Abweichung vom Durchschnitt.

Dazu kommt das, was sich schwer in eine AGENTS.md schreiben lässt. Ich profitiere davon, seit 1998 Dinge ins Netz zu stellen. Ich weiß, warum eine URL nicht geändert werden darf, was ein kanonischer Link ist, warum ein Feed seine GUIDs behalten muss und wo Umzüge typischerweise Rankings kosten. Der Agent weiß das auch – aber nur, wenn ich ihn danach frage. Wer die richtigen Fragen nicht kennt, bekommt auf sie keine Antwort.

Mein Fazit bleibt trotzdem: Baukästen und CMS können weg. Für GründerInnen mit klarer Marke, etwas Geduld für den Einstieg und dem Willen, Git wenigstens zu verstehen, ist eine statische Website mit Cloudflare Pages heute die bessere Wahl. Und wer noch nicht weiß, was er will, dem hilft auch kein Baukasten – er versteckt das Problem nur hinter einem hübschen Template. Dann ist die Arbeit an der Marke dran, nicht die an der Website.

Wie es weitergeht

Nächste Woche folgt der Schwesterartikel. Dort geht es nicht um den Stack, sondern um das, was darin liegt: Wie sich große Content-Änderungen auf einmal erledigen lassen, wie Inhalte, Redaktionsregeln und Tonalität als Dateien neben den Texten leben, wie ein Agent damit schreibt und prüft – und warum das die eigentliche Pointe dieses ganzen Umbaus ist.