Unter der Haube

Warum ich in 2026 mein eigenes CMS gebaut habe

RC
Robin Collet 25. Juli 2026 · ~6 Min. Lesezeit

Es gibt viele gute Wege, einen Blog online zu stellen. Ich habe keinen davon gewählt und stattdessen mein eigenes CMS geschrieben. Das war nicht die vernünftige Entscheidung, und ich will ehrlich damit umgehen, denn die meisten „Ich hab mein eigenes CMS gebaut”-Beiträge springen direkt zur Ehrenrunde. Manches ist im Folgenden gut begründet, manches ist einfach Geschmackssache. Ich sage jeweils dazu, was davon was ist.

Was es nicht geworden ist

„Not invented here” ist kein Grund. Hier sind die tatsächlichen Gründe, angefangen bei dem, bei dem ich am wenigsten objektiv bin.

  • Bei WordPress muss ich meine Voreingenommenheit gleich zugeben: Ich kann es nicht ausstehen. Es hat als Blog-Software angefangen, und ehrlich gesagt ist es darin bis heute okay. Allerdings wurde es irgendwann zur Standardantwort für jede Corporate-Website dieser Welt, eine Rolle, für die es nie gedacht war und die es nicht besonders elegant ausfüllt. Unter der Oberfläche schleppt es fast zwanzig Jahre Altlasten und Abwärtskompatibilität mit sich herum, die es nie ganz loswird, und dieses Gewicht spürt man in dem Moment, in dem man auch nur leicht vom vorgegeben Pfad abweichen will. Dazu das ständige Patchen und Absichern, das eine öffentliche WordPress-Installation braucht. Bei einer privaten Seite würde ich mehr Abende mit der Pflege verbringen als mit dem Schreiben. Für mich war es ein Nein, noch bevor ich überhaupt bei den technischen Einwänden war.
  • Ein Static-Site-Generator ist eine feine Sache. Schnell, günstig, kaum Angriffsfläche. Fast hätte ich mich für diese Option entschieden. Gescheitert ist es an den drei Dingen, die mir am wichtigsten waren: eine echte Oberfläche zum Schreiben, geplantes Veröffentlichen von Beiträgen und Übersetzungen, die kein nachträglicher Anbau sind. Man kann die generierten Dateien zu allen dreien überreden, aber man spürt das Tool meist die ganze Zeit dagegenhalten.
  • Etwas Gehostetes, Ghost oder ein Setup auf Notion-Basis, ist mit Abstand am wenigsten Aufwand. Wenn ich nur Beiträge hätte schreiben wollen, hätte ich mich angemeldet und wäre vor dem Mittagessen fertig gewesen. Aber es läuft auf fremder Software und nach anderen Vorstellungen und Plänen, und das hier ist eines der wenigen Dinge, die ich ganz für mich haben wollte.

Worum es mir eigentlich ging

Nimmt man den Vergleich weg, stecken darunter eine Handvoll Wünsche. Jede Entscheidung im Code lehnt sich an einen davon an.

Der erste ist Kontrolle, ganz banal gemeint: Wenn mich etwas stört, öffne ich die entsprechende Datei und ändere es. Ich muss auf keinen Plugin-Autor warten und meine Idee nicht so lange zurechtbiegen, bis sie in irgendeine Einstellungsmaske passt. Der zweite ist Mehrsprachigkeit. Die musste von Anfang an im Datenmodell stecken und nicht nachträglich reingefummelt sein, denn ich habe schon zweisprachige Seiten am Leben gehalten, die auf Tools liefen, die mit Annahme einer einzigen Sprache gebaut waren. Auf eine Wiederholung davon hatte ich keine Lust.

Der dritte Wunsch wird oft unterschätzt, und er hat viel damit zu tun, dass ich eben nicht nur ein Theme drüberlegen wollte. Ich wollte kein fertiges Gerüst nehmen und neu anstreichen. Die Seite sollte durch und durch nach „mir“ aussehen. Bei den meisten Plattformen bekommt man ein Grundgerüst und darf sich die Farben aussuchen, aber wer genau hinschaut, sieht immer die Nähte: dieses leise Gefühl, dass das eigene Design genau da aufhört, wo die Annahmen des Themes anfangen. Ich wollte eine durchgehende visuelle Handschrift, vom Hero auf der Startseite bis zum Impressum und bis in die Abstände in einem Code-Block. Und das ist ungleich leichter, wenn einem Markup und CSS von oben bis unten selbst gehören und darunter nichts klammheimlich die eigenen Entscheidungen überstimmt.

Und der letzte Wunsch ist der, der am Ende den Ausschlag gegeben hat.

Das Überzeugendste an einem Portfolio ist für einen Entwickler die Software, auf der das Portfolio selbst läuft.

Jeder kann die Werkzeuge aufzählen, die er kennt. Eine Website, die man aufrufen und lesen kann und in der echte Entscheidungen und echte Fehler noch immer zu finden sind, spricht für sich selbst. Das allein reichte mir schon aus, um anzufangen.

Was es gekostet hat

Nun zu dem Teil, den die Ehrenrunden auslassen. Wenn man etwas selbst entwickelt, muss man all die Probleme erneut lösen, die die etablierten Plattformen und Tools bereits vor einem Jahrzehnt bewältigt haben. Und zwar alle. Ohne Ausnahmen. Ich habe die Modelle geschrieben, einen ordentlichen Bestätigungsdialog erstellt, nachdem sich der erste billige Inline-Dialog als fehlerhaft erwiesen hatte und ich ihn zugunsten eines echten <dialog>entfernen musste. Ich habe den Blog-Index paginiert, den RSS-Feed begrenzt und die Deployment-Pipeline aufgebaut.

Jede Funktion muss ich erst selbst erstellen, bevor ich sie nutzen kann. Und da niemand sonst sie testet, sind die von mir geschriebenen Tests mein einziges Sicherheitsnetz. Meine CI läuft mittlerweile mit Postgres, und zwar aus genau einem Grund: Ein paar Fehler sind bei SQLite durchgerutscht und traten erst in der echten Datenbank zutage, eine demütigende Erinnerung daran, dass „läuft lokal“ und „funktioniert“ zwei ganz unterschiedliche Dinge sind.

Tipp

Wenn du bis zum Wochenende etwas veröffentlichen möchtest, lass das lieber. Installiere Ghost, schreibe deinen ersten Beitrag und genieße deinen Samstag. Ein eigenes Website CMS zu erstellen macht nur dann Sinn, wenn das Erstellen selbst der Teil ist, den du wirklich willst.

Warum es sich trotzdem gelohnt hat

Für mich war es das, denn das selbst Erstellen ist der springende Punkt. Es war kein Hindernis auf dem Weg zum Schreiben oder zur Verwaltung von Inhalten. Jede Hürde auf die ich stieß, wurde zu etwas, das ich verstehe, statt zu einem auswendig gelernten Workaround. Der Umgang mit den Zeitzonen, das Block-System, die Art und Weise, wie sich ein dummes NULL in den Featured-Slot eingenistet hat: Bei jedem davon weiß ich, warum es so funktioniert, wie es funktioniert, weil ich dabei war, als es nicht funktionierte.

Was am Ende steht, ist eine Website, die ich bis ins kleinste Detail erklären kann, vom Schema bis hin zum Abstand zwischen diesen beiden Zeilen. Nichts daran ist übernommen, nichts übertüncht etwas, das ich lieber nicht ansehen würde. Das ist es, was ein Portfolio beweisen soll, und genau das was WordPress mich niemals hätte sagen lassen. Der letzte Beitrag war die grobe Tour. Dieser hier war das „Warum“. Nächstes Mal zeige ich dir einfach etwas, das ich gebaut habe.