Bis vor wenigen Wochen hieß einen Beitrag für dieses Blog zu schreiben: Code-Editor öffnen, eine Markdown-Datei in einem bestimmten Ordner anlegen, prüfen, ob das Frontmatter stimmt, committen, pushen, das Deploy abwarten. Für einen Beitrag. Jedes Mal.
Es war nicht furchtbar — es funktionierte. Aber unbequem auf jene heimtückische Art, die einen Dinge aufschieben lässt. „Den Text schreibe ich morgen“, woraus nächste Woche wird, woraus nie wird.
Das alte System: schön in der Theorie, mühsam in der Praxis
Die Site lief auf Astro mit statischen Seiten. Die Beiträge waren .md-Dateien in einem Projektordner. Jeder Post hatte oben sein YAML-Frontmatter (Titel, Datum, Tags, Beschreibung, Bild) und darunter den Inhalt in Markdown.
Um zu veröffentlichen, brauchte es:
- VS Code öffnen
- Die Datei im richtigen Ordner mit dem richtigen Namen anlegen
- Das Frontmatter fehlerfrei schreiben (ein falsch gesetztes Komma, und der Build flog auseinander)
- Den Inhalt in Markdown verfassen
- Lokal testen, ob alles passt
- Committen, pushen, das Deploy auf Cloudflare Pages abwarten
Sechs Schritte. Um einen Gedanken zu veröffentlichen.
Vom Bearbeiten eines bestehenden Beitrags ganz zu schweigen: Datei finden, öffnen, editieren, neu committen, neu pushen. Oder ein Bild hochladen: in den Ordner public legen, mit relativem Pfad im Markdown referenzieren, hoffen, sich nicht im Pfad geirrt zu haben.
Es funktionierte, ja. Aber jedes Mal verwandelte diese Reibung eine Fünf-Minuten-Operation in ein Zwanzig-Minuten-Ritual. Und Reibung tötet auf Dauer die Regelmäßigkeit.
Die Idee: Was, wenn ich mir ein Admin-Panel baue?
Irgendwann fragte ich mich: Wie lange würde es dauern, mir ein anständiges Admin-Panel zu bauen? Kein WordPress, kein Ghost, kein Headless-CMS mit monatlichem Abo. Etwas Eigenes, das genau das tut, was nötig ist, und nicht mehr.
Die traditionelle Antwort wäre gewesen: lange. Tage Arbeit, um es zu bauen, oder Wochen, um ein bestehendes CMS anzupassen — mit seinen Meinungen darüber, wie Dinge zu funktionieren haben, seinen Abhängigkeiten, seinen Updates.
Aber die Antwort im Jahr 2026 sieht anders aus.
Bauen ist schneller geworden als auswählen
Ich habe mich mit Claude Code (einem Werkzeug für generative KI im Code) hingesetzt und das System Stück für Stück gebaut. Nicht, indem ich zufälligen Code zum Kopieren generiert habe, sondern indem ich mit ihm gearbeitet habe wie mit einem sehr kompetenten und sehr schnellen Kollegen.
Das Ergebnis ist ein vollständiges Admin-Panel, das mir erlaubt:
- Beiträge mit einem WYSIWYG-Editor zu schreiben: kein händisches Markdown mehr, ich schreibe wie in einem normalen Texteditor, mit Toolbar für Fett, Kursiv, Überschriften, Listen, Zitate, Code, Links und Bilder
- Bilder direkt in den Editor zu ziehen: sie werden automatisch auf Cloudflare R2 geladen und an der richtigen Stelle eingefügt
- Metadaten in einer klaren Sidebar zu verwalten: Veröffentlichungsstatus, Datum, Tags, Titelbild, alles griffbereit
- Mit einem Klick zu speichern: wie in jeder normalen Anwendung
- Die Beitragsliste zu sehen in einem Dashboard mit sofortigen Statistiken
Und das Ganze speichert die Inhalte als Markdown in der Datenbank, sodass das Frontend des Blogs sie genauso rendert wie zuvor.
Was unter der Haube steckt
Für die technisch Neugierigen: Die Site läuft weiter auf Astro, ist aber von Static Generation auf Server-Side Rendering auf Cloudflare Workers umgezogen. Das heißt, die Seiten werden im Moment des Aufrufs erzeugt (beim ersten Mal), was mir dynamische Inhalte erlaubt, ohne auf Geschwindigkeit zu verzichten.
Die Daten leben auf Cloudflare D1, einer SQLite-Datenbank, die im Edge-Netzwerk von Cloudflare verteilt ist. Die Bilder auf Cloudflare R2, einem S3-kompatiblen Object Storage. Die Authentifizierung nutzt JWT mit über die Web Crypto API signierten Tokens.
Der WYSIWYG-Editor basiert auf Tiptap, einem Editor-Framework auf ProseMirror (derselben Engine, die unter Notion liegt). Das Interessante: Unter dem WYSIWYG werden die Inhalte dank einer dedizierten Erweiterung in sauberes Markdown konvertiert. Ich schreibe visuell und speichere in einem portablen Format.
Für die Sicherheit, weil ein im Internet exponiertes Admin-Panel sicher sein muss, gibt es:
- Cloudflare Turnstile auf der Login-Seite (der unsichtbare Nachfolger des CAPTCHA)
- Rate Limiting zur Vorbeugung gegen Brute Force
- Strikte Validierung jedes Inputs, jedes Uploads, jedes Dateipfads
- Konstantzeitvergleich der Credentials zur Vorbeugung gegen Timing-Angriffe
- Magic-Bytes-Prüfung der hochgeladenen Dateien, nicht nur der Endung
Kein Admin-Framework, kein Plugin, keine schwere Abhängigkeit. Nur der Code, der nötig ist, dort wo er nötig ist.
Der wahre Wandel ist nicht technisch
Das Interessante an dieser Geschichte ist nicht die Technologie. Es ist die Verschiebung in der Kosten-Nutzen-Rechnung.
Bis vor Kurzem standen vor einem solchen Bedarf folgende Optionen:
- Etwas Bestehendes anpassen: WordPress, Ghost, Strapi, Dutzende von CMS mit ihren Meinungen, ihren Lernkurven, ihren laufenden Kosten, ihren Schwachstellen, die zu patchen sind
- Es bauen lassen: ein Angebot, Wartezeiten, Feedback-Iterationen, Kompromisse darüber, wie „das Framework will, dass es funktioniert“
- Es selbst bauen: Wochen Arbeit, Tests, Debugging, mit dem realen Risiko, auf halbem Weg aufzugeben
Heute gibt es eine vierte Option: es sich selbst zu bauen, mit der KI als Beschleuniger. Nicht als Ersatz für das Denken, sondern als Verstärker der Ausführungsfähigkeit.
Ich wusste, was ich wollte. Ich wusste, wie es funktionieren musste, welches Nutzungserlebnis ich suchte, welche Kompromisse ich einzugehen bereit war. Die KI hat diese Vision in funktionierenden Code verwandelt, in einer Geschwindigkeit, die für eine einzelne Person bisher schlicht unmöglich war.
Und es ist kein „generierter“ Code: Es ist Code, den ich gelenkt, geprüft, getestet habe und den ich Zeile für Zeile verstehe. Denn es geht nicht darum, das Denken zu delegieren — es geht darum, das Tippen zu delegieren.
Schneller selbst zu bauen, als ein Angebot einzuholen
Dieser Satz klingt provokant, aber für eine bestimmte Kategorie von Projekten wird er buchstäblich wahr.
Ich rede nicht von Enterprise-Systemen, Plattformen mit tausenden Nutzern oder geschäftskritischer Software. Ich rede von all jenen mittleren Projekten, die früher in ein Niemandsland fielen: zu spezifisch für eine Off-the-shelf-Lösung, zu klein, um eine ernsthafte Investition zu rechtfertigen, zu ermüdend, um sie von Hand zu bauen.
Mein Admin-Panel fällt genau in diese Kategorie. Kein bestehendes CMS hätte exakt das geliefert, was ich wollte, in der Art, wie ich es wollte. Es bauen zu lassen hätte Briefings, Angebote, Revisionen, Deploys verlangt. Es selbst von Hand zu bauen hätte Wochen verschlungen, gestohlen aus Abenden und Wochenenden.
Stattdessen habe ich es in 25 Minuten gebaut. Es funktioniert. Es gehört mir. Es tut genau, was nötig ist. Und wenn ich morgen etwas ändern will, geht das in Minuten.
Die Zukunft ist maßgeschneidert
Ich glaube, wir treten in eine Ära ein, in der maßgeschneiderte Software jedem zugänglich wird, der eine klare Vorstellung davon hat, was er will, und über anständige technische Fähigkeiten verfügt. Es braucht kein Entwicklerteam mehr. Es braucht kein üppiges Budget mehr. Es braucht das Wissen, was man will, und die Fähigkeit, das Werkzeug zu führen.
Es ist wie der Übergang vom Schneiderhandwerk zur Konfektionsware, nur umgekehrt: wir kehren zur Maßarbeit zurück, nur dass der Schneider jetzt blitzschnell ist und einen Bruchteil von früher kostet.
Für alle, die im Digitalen arbeiten (Entwicklerinnen, Designer, Marketer, Unternehmer), verschieben sich damit selbstverständlich die Rechnungen.
Was du mitnimmst
Maßgeschneidert zu bauen ist für mittlere Projekte schneller geworden, als eine bestehende Lösung auszuwählen.
KI ersetzt nicht das Produktdenken, sie verstärkt die Ausführungsfähigkeit derer, die schon wissen, was sie wollen.
Das mittlere Segment der SaaS-CMS bröckelt zuerst; der Enterprise-Bereich bleibt, aber für Infrastruktur, nicht für das Produkt.
Fragen & Antworten
Warum ist es schneller, ein maßgeschneidertes CMS zu bauen, als ein fertiges zu suchen?
Weil mit Agenten wie Claude Code 25 Minuten reichen, um ein statisches Astro-Blog in ein dynamisches System mit WYSIWYG-Editor, Authentifizierung, Medienbibliothek und Redirect-Verwaltung zu verwandeln. Die Lernkurve eines Off-the-shelf-CMS (WordPress, Strapi, Sanity, Contentful) — Installation, Anpassung, Kompromisse, Lock-in — ist länger als die Zeit, die nötig ist, um exakt das zu schreiben, was man braucht. Das Verhältnis Build vs. Buy hat sich verschoben.
Wann ergibt ein maßgeschneidertes CMS gegenüber einem fertigen Sinn?
Wenn (1) die Anforderungen präzise und nicht generisch sind; (2) man bereits eine Site oder einen Stack hat, den das CMS respektieren und nicht diktieren soll; (3) man null Abhängigkeit von einem SaaS will, der schließen, den Preis ändern oder die API umbauen kann. Es ergibt keinen Sinn, wenn das Off-the-shelf-CMS bereits liefert, was nötig ist, und die Integrationskosten gering sind — für sehr standardisierte Projekte bleibt boring pragmatism unschlagbar.
Was ändert sich strategisch für SaaS-Unternehmen, die CMS verkaufen?
Das untere Marktsegment (persönliche Blogs, kleine Verlage, Portfolios) beginnt in Richtung Custom-Lösungen abzufließen. Das obere Segment (Enterprise Content Operations) bleibt — denn dort liegt der Wert nicht im CMS, sondern in der Infrastruktur drumherum (CDN, Sicherheit, Workflow, Compliance). Die Unternehmen in der Mitte, die generische CMS zu SaaS-Preisen verkaufen, müssen schnell klären, was sie verteidigbar macht: fortgeschrittene Features, Netzwerkeffekte oder akkumulierte Kundendaten.
Was bedeutet das für alle, die im digitalen Produkt arbeiten?
Der Wert liegt nicht mehr im Zugang zu vorgefertigten Funktionalitäten, sondern im Urteil darüber, welche Funktionalitäten wirklich gebraucht werden. Eine Produktmanagerin, die heute jede Einschränkung des gewählten CMS akzeptiert, weil es alle benutzen, arbeitet mit Annahmen aus der Prä-GenAI-Ära. Wer in Spezifikationen denken kann, einem KI-Agenten Maßarbeit zu beauftragen weiß und erkennt, wann Custom nicht nötig ist, operiert auf einer anderen Produktivitätsebene.