Unsere neue Webseite: gebaut mit dem myFlow•OS statt mit dem Baukasten

Eine neue Unterseite, eine Landingpage für eine Kampagne, eine Grafik, die einen Ablauf erklärt: Bei den meisten Firmen heißt das Agentur-Briefing, Abstimmungsrunden und Wochen Vorlauf. Oder man bleibt im Rahmen dessen, was der Baukasten hergibt.

Unsere neue Webseite haben wir anders gebaut - mit dem myFlow•OS, dem Betriebssystem, mit dem wir auch in Kundenprojekten arbeiten. Der Effekt: Aus einer Idee wird in Tagen eine fertige Seite, und zwar genau so, wie wir sie haben wollen.

Individuell statt Standard-Web-Baukasten

Wer die Startseite öffnet, sieht rechts ein kleines Schaufenster: Ein Support-Postfach sortiert sich von selbst, Anfragen bekommen Kategorie und Antwortvorschlag. Mit einem Schieber lässt sich darunter schauen - dort läuft der Ablauf dahinter Schritt für Schritt mit. Weiter unten baut sich beim Scrollen unser Weg vom ersten Gespräch bis zum eigenen Team auf, und das Logo zeichnet sich Punkt für Punkt.

So etwas ist mit einem Baukasten kaum zu machen. Dort bekommt man Bausteine, die für alle passen - wer etwas Eigenes will, stößt schnell an Grenzen oder landet bei teuren Sonderlösungen. Bei uns ist jede Grafik und jede Animation ein Stück der Seite selbst: gebaut aus einer Beschreibung, im Browser geprüft, angepasst, fertig. Dieselbe Arbeitsweise trägt für Kampagnenseiten, Erklärgrafiken für Blogbeiträge oder Projektseiten mit Screenshots.

Gesteuert per Prompt

Das Wichtigste an der neuen Arbeitsweise sieht man der Seite gar nicht an: Wir steuern sie in normaler Sprache. Kein Einloggen in ein Redaktionssystem, kein Hochladen von Bildern in drei verschiedene Werkzeuge, kein Hin- und Herkopieren zwischen Word, Bildbearbeitung und Webseite.

Stattdessen sagen wir dem OS, was wir wollen - so, wie man es einer Kollegin sagen würde:

• „Bau aus diesen Notizen einen Blogbeitrag und verlinke ihn beim passenden Projekt.”
• „Nimm aus der Präsentation zwei Screenshots für das Projekt - und mach die Kundennamen unkenntlich.”
• „Stell den Energiehändler auf Position zwei, danach Tengelmann.”
• „Schreib bei den beiden Projekten ‚Ein Stadtwerk’ statt des Kundennamens.”

Das OS setzt es um, zeigt uns das Ergebnis im Browser, und wir entscheiden. Aus einer Stunde Klickarbeit wird ein Satz und ein prüfender Blick.

Erst verstehen, dann bauen

Am Anfang stand kein Design-Auftrag, sondern die Frage, was die Seite leisten soll: Wer liest sie, was soll danach passieren, welche Inhalte haben wir, welche fehlen. Daraus hat das OS mit uns einen klickbaren Prototyp gebaut, den wir im Browser durchgehen und verbessern konnten, bevor die echte Seite entstand.

Umgesetzt haben wir ihn dann mit Astro. Man muss es nicht kennen - es macht aus einfachen Textdateien fertige, sehr schnelle Webseiten. Gebaut hat ein KI-Assistent, der nach den Regeln des myFlow•OS arbeitet. Entschieden haben wir.

Inhalte als Textdateien, Freigaben über das OS

Die meisten Webseiten haben ein Redaktionssystem (CMS) mit Login, Datenbank und Formularen, in die man Texte eintippt. Wir haben keins.

Jeder Blogbeitrag und jedes Projekt ist bei uns ein Ordner mit einer einfachen Textdatei und den Bildern dazu. Das klingt unscheinbar, hat aber Folgen:

• Inhalte entstehen dort, wo wir ohnehin arbeiten. Aus Notizen, einem Gesprächsprotokoll oder einem Fachartikel baut das OS einen Beitrag - mit Bildern, Bildunterschriften und Verweisen auf passende Projekte.
• Jede Änderung ist nachvollziehbar. Wer wann was geändert hat, ist lückenlos dokumentiert und lässt sich zurücknehmen.
• Freigaben steuert das OS. Ein Beitrag geht erst live, wenn wir ausdrücklich zugestimmt haben - das OS fragt aktiv nach. Was freigegeben ist, ist eingefroren: Ändert sich danach auch nur ein Bild, baut sich die Seite nicht mehr, bis wir erneut zugestimmt haben.

Das ist dasselbe Prinzip wie in unseren Automatisierungsprojekten: Die Maschine bereitet vor, der Mensch gibt frei.

Geprüft wird automatisch

Bevor eine neue Fassung live geht, prüft ein Programm jede einzelne Seite - in Chrome, Firefox und Safari, auf dem Handy und am großen Bildschirm: Lädt alles? Rutscht nichts zur Seite weg? Funktionieren Menü, Filter und Links? Was früher ein Nachmittag Durchklicken war, dauert jetzt ein paar Minuten.

Wie viel das wert ist, haben wir gleich zu Beginn gesehen: Bei der Messung der Ladezeit bekam unsere Startseite erst einmal null Punkte - obwohl sie schnell war. Eine kleine Animation im Projekt-Karussell hatte die Messung des Browsers gestört. Mit bloßem Auge hätte das niemand bemerkt, Google schon. Nach einer kleinen Änderung stand die Seite bei 100.

Und was heißt das für euch?

Unsere Webseite ist ein kleines Beispiel für ein großes Muster: Was sonst Wochen und viele Abstimmungen braucht, wird zu einem klaren Ablauf - mit Prüfpunkten, einer ausdrücklichen Freigabe und dem Menschen an der Stelle, an der es auf ihn ankommt.

Genau so gehen wir in Fachbereichen vor - bei Mahnungen, im Kundenservice, in der Energiebeschaffung. Wie das aussehen kann, zeigen unsere Leistungen.

Für Technik-Interessierte

Der Stack ist bewusst unspektakulär: Astro baut statische Seiten, Inhalte sind Markdown im Git-Repository, ausgeliefert wird per nginx im Docker-Container, gebaut in einer GitHub-Actions-Pipeline je Stufe (Entwicklung, Vorschau, live). Geprüft wird mit Playwright in Chromium, Firefox und WebKit.

Interessanter ist, wie die Teile zusammenspielen:

• Freigabe als Build-Gate. Jede Freigabe speichert einen Fingerabdruck von Text und Bildern. Weicht ein freigegebener Inhalt davon ab, bricht der Build ab - statt Rechten in einem CMS schützt der Build selbst.
• Regeln im Schema. Pflichtfelder, erlaubte Tags und die Liste der Kunden, die wir namentlich nennen dürfen, stehen im Inhaltsschema. Was nicht passt, wird gar nicht erst gebaut.
• Ein KI-Assistent mit Hausordnung. Der Assistent arbeitet nach Regeln, die im Repository liegen: Er fragt nach der Freigabe, ändert Freigegebenes nicht nebenbei und prüft seine Arbeit mit Playwright, bevor er fertig meldet.
• Null Drittanbieter. Schriften, Bilder, Skripte - alles kommt vom eigenen Server. Eine Content Security Policy mit Hashes je Seite lässt nur unsere eigenen Skripte laufen.