Es gibt eine bestimmte Art von Problem, die sich nicht als Problem ankündigt. Sie kommt als Reibung daher. Ein Bug hier. Ein Workaround dort. Ein Plugin, das einen Fix braucht, bevor das Tool funktioniert, das das Plugin braucht. Sie machen weiter. Sie liefern Dinge aus. Sie reden sich ein, so verhalten sich komplexe Systeme eben.

Sie liegen falsch. Die Reibung versucht, Ihnen etwas zu sagen. Sie hören nur noch nicht hin.

Ich bin komplett auf Etch umgestiegen.

In einer WordPress-Builder-Landschaft, die uns alles gebracht hatte, vom aufgeblähten Seiten-Wirrwarr bis zu eigensinnigen Frameworks, die einen aus dem eigenen Markup aussperren, fühlte sich Etch anders an. Saubere Architektur. Logische API. Es behandelte Entwickler wie Erwachsene. Ich habe mich festgelegt — auf Etch und ACSS neu aufgebaut, echte Zeit investiert, bin tief eingestiegen.

Dann fing die Reibung an.

ACSS registriert seinen Filter-Hook doppelt. Schriftarten brechen still und leise, abhängig von der Ladereihenfolge. Etchs array_unique()-Aufruf hinterlässt nicht-sequenzielle Array-Schlüssel, die PHPs json_encode() dann als Objekt statt als Array serialisiert. Der gesamte Font-Stack bricht zusammen. Und Etchs aggressives REST-API-Polling — eine durchaus vernünftige Implementierungsentscheidung — löst die Rate-Limits von CrowdSec aus und lässt Ihren Builder von der eigenen Website aussperren.

Jeder Bug war behebbar. Ich habe sie behoben. Ich habe ein MU-Plugin geschrieben, um die Konflikte zu patchen. Ich habe die REST-API-Pfade in CrowdSec auf die Whitelist gesetzt. Ich habe die ganze Kette dokumentiert.

Und dann hielt ich inne und schaute mir an, was ich gebaut hatte.

Ich schrieb Infrastruktur, um ein Tool zu reparieren, dessen ganzer Zweck es war, Infrastruktur zu reduzieren.

Das ist der Moment, dem man Aufmerksamkeit schenken sollte. Nicht die Bugs — Bugs gibt es in jeder Software. Das Signal war das Muster. Jede Lösung fügte eine Schicht hinzu. Jede Schicht fügte eine Abhängigkeit hinzu. Jede Abhängigkeit vergrößerte die Angriffsfläche, an der als Nächstes etwas schiefgehen konnte.

Ich fing an, den Faden zu ziehen.

WordPress speichert Inhalte in MySQL. Nicht in Dateien. Nicht in Git. In einer Datenbank, die Sie über eine Abstraktionsschicht abfragen, die Sie über Plugins versionieren, die nie ganz produktionsreif waren, die Sie über noch ein weiteres Tool sichern, die Sie über Export-XML migrieren, aus dem kein Diff-Tool schlau wird.

Der Builder sollte die Antwort auf die Komplexität sein. Stattdessen legte er die Komplexität offen, die schon immer da war — die Komplexität, die ich als Preis dafür akzeptiert hatte, auf WordPress Geschäfte zu machen.

Das Problem war nie Etch.

Das ist der Teil, bei dem man einen Moment innehalten sollte.

Etch hat mich nicht im Stich gelassen. Es hat mich diagnostiziert.

Die Annahme, die ich nie hinterfragt hatte, war diese: dass WordPress das richtige Fundament für eine inhaltsgetriebene professionelle Website ist. Es war eine vernünftige Annahme — die halbe Welt läuft auf WordPress. Aber vernünftige Annahmen sind genau die, die man am sorgfältigsten prüfen muss, weil sie diejenigen sind, die sich niemand die Mühe macht herauszufordern.

Sobald ich anfing, am Faden zu ziehen, überlebte die Annahme die Prüfung nicht. WordPress ist eine Publishing-Plattform aus einer Ära, in der Inhalte in einer Datenbank lebten und man sie pro Anfrage abrief. Darin ist es außerordentlich gut. Aber was ich tatsächlich bauen wollte, war keine dynamische Anwendung. Es war eine Sammlung von Dokumenten — Insights, Services, Use Cases, Library-Einträge —, die sich selten änderten, Versionskontrolle brauchten und überall auf der Welt sofort laden sollten.

Für dieses Problem ist eine Datenbank das falsche Substrat. Ich hatte das falsche Problem gelöst.

Das Problem ist selten das Problem. Das sage ich Kunden seit Jahren. Es stellt sich heraus, dass es auch für den eigenen Tech-Stack gilt.

Die Architektur, die daraus entstand.

Sobald die Annahme zerbrach, war die Richtung offensichtlich.

Inhalte als Markdown-Dateien, in Git committet. Sechs typisierte Content Collections mit sauberen Schemas und Querverweisen — Insights, Services, Use Cases, Library, FAQs, Podcast. Astro zur Build-Zeit, das diese Dateien in statisches HTML umwandelt. Cloudflare Pages, das das Ergebnis an jeden Edge-Knoten des Planeten verteilt.

Keine Datenbank. Kein Builder. Keine Plugin-Angriffsfläche, die gepflegt oder verteidigt werden muss.

Die Inhalte sind einfach Dateien. Diffbar. Taggbar. Lesbar in jedem Editor, auf jedem Gerät, ohne Verbindung zu irgendetwas. Git ist gleichzeitig Versionskontrollschicht, Backup, Changelog und Audit-Trail. Das gesamte Deployment ist ein git push.

Jede „Lösung“, die ich auf WordPress gestapelt hatte, um diese Eigenschaften zu erreichen — Backup-Plugins, Migrationstools, Versionskontroll-Workarounds, REST-API-Patches — verschwindet einfach. Nicht weil ich sie gelöst habe. Weil ich das Substrat entfernt habe, das sie überhaupt erst nötig gemacht hat.

Etch hat mich nicht im Stich gelassen. Es hat mich diagnostiziert.

Der vielversprechendste Builder im WordPress-Ökosystem hat mich zu einer Architektur geführt, die gar keinen Builder braucht.

Das ist keine Kritik an Etch. Das Produkt ist wirklich gut gemacht. Für Websites, bei denen WordPress tatsächlich das richtige Substrat ist — komplexe Anwendungen, dynamische Inhalte, kundenverwaltete CMS-Szenarien — bleibt Etch eines der stimmigsten verfügbaren Tools.

Aber für meine Website — eine inhaltsgetriebene Beratungspräsenz, die schnell laden, sicher bleiben und mich nie um zwei Uhr nachts überraschen soll — war die Diagnose eindeutig. Und ich wäre ohne die Reibung nie dorthin gekommen.

Die Bugs waren nicht das Problem. Die Bugs waren der Bote.

Welches Tool verteidigen Sie gerade, das eigentlich nur eine tiefere Annahme offenlegt, die Sie noch nicht hinterfragt haben?