Wenn du willst, dass etwas richtig gemacht wird, mach es selbst. Mit KI.

Unsere Website lädt jetzt in weniger als einer Sekunde. Blitzschnell.

Anfang dieser Woche, am 21. Oktober, haben wir unsere vollständig neu aufgebaute Website veröffentlicht. Aber die Performance war nicht der einzige Grund für den Neuaufbau.

Es gibt einige Probleme, die fast jedes kleine Unternehmen und jedes Marketingteam kennen dürfte.

Und natürlich möchten Sie die Inhalte so schnell wie möglich veröffentlichen, zwischendurch Änderungen vornehmen und nachjustieren, wenn das Ergebnis anders aussieht als ursprünglich gedacht. Doch Ihre Änderungen können schnell auf Platz zwei oder drei der Prioritätenliste rutschen. Unerwartetes Verhalten der Website, technische Komplexität oder zusätzlich benötigte Funktionen können die Veröffentlichung verzögern und Ihre Ideen im Backlog festhalten.

Unsere alte Website war langsam, schwerfällig und schwierig zu pflegen. Im Laufe der Zeit hatten sich zahlreiche Verbesserungen an der Benutzeroberfläche und uneinheitliche Komponenten angesammelt. Normalerweise würde ein solcher Neuaufbau in Phasen erfolgen: die bestehende Website migrieren, Komponenten vereinheitlichen und anschließend ein neues Design einführen. Doch trotz Hunderten von Seiten haben wir uns entschieden, alles in einem Zug umzusetzen.

Wie haben wir also WordPress und PHP hinter uns gelassen und sind zu etwas Schlankerem, Schnellerem und Modernerem gewechselt – mit einem Hauch von Pumpkin Spice Latte? Hier ist ein Rückblick auf unseren Weg zu Next.js und Payload CMS, während unser Designer an einer neuen UI/UX arbeitete und Codex die Codegenerierung, Implementierung und Bereitstellung übernahm.

Das Problem war nicht nur die Website

Etwa ein Jahr lang hatte ich die technischen und organisatorischen Probleme unserer Website hingenommen.

Das größere Problem war aber, wie schwierig es war, unser Wissen und unsere Ideen direkt an potenzielle Kunden weiterzugeben.

Als Unternehmer und Gründer spreche ich regelmäßig mit Kunden, lerne ihre Bedürfnisse kennen und nehme mit unserem Entwicklungsteam an Besprechungen zur Architektur technischer Lösungen teil.

Unsere Entwickler arbeiten direkt mit Kunden. Sie kennen deren Probleme, wissen, was ihr Geschäft verbessern könnte, und haben oft großartige Ideen, die es wert sind, geteilt zu werden. Dasselbe gilt für unser Vertriebsteam, das ständig mit Kunden kommuniziert und ihre Probleme und Bedürfnisse erkennt.

Die Frage ist: Wie verkürzen wir den Weg zwischen diesen Ideen und dem Kunden und bewahren dabei die ursprüngliche Vorstellung und die Absichten des Autors?

Mir wurde klar, dass KI uns helfen könnte, diese unnötigen Zwischenschritte zu beseitigen.

Und Änderungen, die früher einen Tag dauerten, konnten jetzt in wenigen Minuten erledigt werden.

Dieser Artikel selbst ist ein gutes Beispiel. Ich diktiere meine Gedanken, die nicht immer besonders strukturiert sind. Dann lese und prüfe ich das Ergebnis, verschiebe Absätze, präzisiere die Beschreibung von Problemen oder gebe einfach die Anweisung: „Stelle diese Probleme als separate Blöcke auf der Seite dar.“

Genau das wollte ich ermöglichen: eine Website, auf der Menschen, die sich wirklich mit dem Thema auskennen, ihre Ideen direkt vermitteln, sofort verfeinern und ohne unnötige Übergaben veröffentlichen können.

KI sollte die Menschen, die die Arbeit leisten, näher an den Kunden bringen, statt eine weitere Ebene zwischen ihnen zu schaffen.

Der langweilige Teil: Reparieren wir, was wir schon haben

Am 1. Oktober 2026 begann ich mit dem Umbau der Website.

Meine erste Idee war einfach: die bestehende Website aufräumen, die Codebasis überarbeiten, unnötige Duplikate entfernen und die Performance verbessern.

Da ich aber nicht in kurzer Zeit Unmengen an Code schreiben konnte, entschied ich mich für Codex.

Ich prüfte den PHP-Code und stellte fest, dass fast jede Seitenvorlage erhebliche Code-Duplikate enthielt.

Mit Codex konnte ich wiederverwendbare Komponenten herauslösen, Duplikate über mehrere Seiten hinweg beseitigen, die Codebasis verkleinern und die Performance verbessern.

Das Interessante daran: Die Prompts waren ziemlich einfach.

Zum Beispiel:

Nimm diesen Abschnitt, [Abschnitts-ID aus der gerenderten HTML-Seite angeben], ersetze ihn und extrahiere ihn als wiederverwendbare Komponente. Prüfe alle anderen Seiten der Website und ersetze die entsprechenden Abschnitte durch die neue Umsetzung. Entferne anschließend sämtlichen alten und ungenutzten Code und überprüfe deine Arbeit.

Im Grunde war das alles.

Dabei fand ich noch etliche weitere Probleme.

Manche Navigationssymbole, die mit 32 Pixeln angezeigt wurden, waren beispielsweise Bilddateien von jeweils etwa einem Megabyte.

Man stelle sich vor: ein Bild mit einem Megabyte laden, nur um ein winziges Navigationssymbol anzuzeigen.

Also bat ich Codex:

Nimm [Bild], analysiere es, skaliere es bei Bedarf hoch und konvertiere es ins WebP-Format. Optimiere es für schnelle Seitenladezeiten, passe es an die tatsächlichen Darstellungsmaße an (zum Beispiel 32 × 32 Pixel) und reduziere die Dateigröße so weit wie möglich, ohne die visuelle Qualität zu beeinträchtigen.

Das wiederholten wir auf der gesamten Website: Wir ersetzten unnötig große Grafiken und räumten die Codebasis auf.

Und es funktionierte.

Das fand ich ziemlich beeindruckend.

An dieser ersten Phase arbeitete ich vom 1. bis zum 10. Oktober ungefähr vier Stunden pro Arbeitstag, Wochenenden ausgenommen.

Das waren insgesamt etwa 28 Stunden, in denen ich die PHP-Codebasis aufräumte und unsere bestehende WordPress-Website optimierte.

Zu diesem Zeitpunkt dachte ich, mit den technischen Änderungen fertig zu sein.

Unser Designer musste nur noch das neue Design abschließen, dann konnten wir weitermachen.

Also legte ich eine Pause von der aktiven Entwicklung ein.

Doch unerwartet wurde alles schlimmer.

Vorfall am 12. Oktober: Die Website ging offline

Zwischen dem 10. und dem 12. Oktober arbeitete ich nicht aktiv an der Website, beobachtete aber weiterhin gelegentlich unsere Servermetriken.

Zuerst dachte ich, meine jüngsten Änderungen könnten die Ursache sein.

Also begann ich mit der Untersuchung und nutzte auch ChatGPT, um die bestehende Website und die Serverkonfiguration genauer zu analysieren.

Dabei stellte sich heraus, dass das Problem offenbar nicht durch meine Codeänderungen verursacht wurde.

Wir hosteten die Website auf einem Server mit 2 GB RAM und zwei CPUs, was meiner Einschätzung nach für unsere Website ausreichen sollte.

Damit will ich nicht sagen, dass GTranslate ein schlechtes Produkt ist.

Wahrscheinlich kamen mehrere Faktoren in unserer Infrastruktur zusammen. Das Plugin erforderte laufende Wartung und Anpassungen von unserer Seite, damit alles korrekt funktionierte.

Ich wusste, dass das Problem wieder auftreten könnte. Außerdem hatten wir etliche Plugins, die im Grunde nur dazu dienten, keinen Code für relativ einfache Funktionen schreiben zu müssen, etwa Kontaktformulare, Übersetzungen und einige weitere Funktionen.

Viele dieser Plugins ließen sich problemlos entfernen oder ersetzen. Idealerweise würde ein neues CMS ihre Funktionen direkt übernehmen.

Und wenn wir unsere Website selbst pflegen und betreuen wollten, war es sinnvoll, von PHP zu etwas zu wechseln, das jeder Salesforce-Entwickler im Schlaf beherrscht: JavaScript.

Deshalb entschieden wir uns serverseitig für Node.js.

Neuaufbau mit Node.js, Next.js, React und Payload CMS

Also begann ich am 12. Oktober mit dem Neuaufbau der Website.

Ich wollte unsere Abhängigkeit von Plugins reduzieren und eine einheitliche Plattform mit einem Content-Management-System, integrierten Übersetzungen und einer Struktur aufbauen, die ich selbst steuern konnte.

Mit JavaScript und Node.js bin ich vertraut und hatte damit bereits mehrere Projekte umgesetzt.

Warum Payload CMS?

Weil es auf Next.js aufbaut und Next.js für mich nach einer ziemlich guten Option aussah.

Ich wollte etwas, mit dem ich in einem vertrauten Technologie-Stack arbeiten konnte, statt weitere Werkzeuge und Abhängigkeiten einzuführen.

Payload und Next.js lieferten uns außerdem eine vernünftige architektonische Grundlage, sodass ich nicht alles von Grund auf erfinden musste.

Und ja, ich war versucht, dem Agenten einfach zu sagen:

Schreibe die gesamte WordPress-Website mit meinem gewünschten Stack aus Node.js, Next.js, React und Payload CMS neu. Mach es richtig, setze es sauber um, überprüfe alles, nutze Unteragenten und lass mich in Ruhe.

Aber ich musste anders vorgehen.

Die erste Alpha-Version war im Wesentlichen eine Eins-zu-eins-Migration, mit Ausnahme der Datenbank.

Wir führten mehrere neue Entitäten ein und strukturierten die Inhaltsverwaltung neu. Die Bedienung des CMS sollte sich eher wie Pipedrive oder HubSpot anfühlen: Navigation links, Inhalte rechts.

Migration der bestehenden Website

Ein wichtiger Punkt: Wir haben nicht die gesamte Website von null an entwickelt.

Wir hatten bereits Inhalte, Seitenstrukturen, Designideen und jahrelange Vorarbeit.

Tatsächlich ist dies wahrscheinlich die vierte größere Version unserer Website.

2019 starteten wir mit dem WordPress-Theme Flaton. Damals hatten wir sogar noch ein anderes Logo.

Später entwickelten wir unser eigenes Theme, aktualisierten es und verbesserten die Benutzeroberfläche laufend.

Unser Designer hatte bereits vor Beginn dieser Migration am neuesten Designsystem gearbeitet.

Es ging also um die vollständige technische Migration und Neustrukturierung einer bestehenden Website – nicht darum, ein komplett neues Produkt von Grund auf zu entwickeln.

Für die Inhaltsmigration extrahierten wir alles aus WordPress und ließen einen KI-Agenten die Inhalte dem neuen Datenbankmodell von Payload CMS zuordnen.

Der Agent half dabei, die Inhalte an die neue Struktur anzupassen, statt einfach alles in eine andere Datenbank zu kopieren.

Außerdem nutzten wir Agenten, um die neue Website bereitzustellen, von der PHP-Implementierung umzuschalten und die alten PHP-Dateien und Konfigurationen vom Server zu entfernen.

War das der eleganteste Ansatz?

Wahrscheinlich nicht.

Aber für uns war es der schnellste Weg, alles zu migrieren und zum Laufen zu bringen.

Reparieren, was den Neuaufbau nicht überstanden hatte

Nach dem ersten Neuaufbau sah ich im Wesentlichen dieselbe Website vor mir, nur mit einigen kleinen Unterschieden.

Dann begann ich, Fehler zu beheben.

Hier funktionierte ein Slider nicht mehr, dort war die Darstellung verschoben. Manche Komponenten verhielten sich nicht mehr genau wie zuvor.

Beim Beheben dieser Probleme stellte ich fest, dass nicht alle Komponenten korrekt ersetzt worden waren.

Einige Seitenvorlagen enthielten noch direkt eingebettetes HTML, während andere neu implementierte Komponenten nutzten, die bereits vorhandenen wiederverwendbaren Komponenten nur ähnelten.

Also begann ich, diese Stellen zu erfassen und sie nacheinander zu bearbeiten.

Der Prompt lautete ungefähr so:

Hier ist ein Abschnitt [Abschnittsname oder ID angeben]. Ersetze ihn bitte durch die vorhandene wiederverwendbare Komponente [Komponentenname angeben]. Behalte dieselbe oder eine ähnliche Semantik und dasselbe oder ein ähnliches Verhalten bei, entferne die alte Implementierung und räume ungenutzten Code auf.

Ich ersetzte weitere alte Implementierungen, verbesserte das serverseitige Rendering, führte Caching ein und optimierte Komponenten.

Vom 12. bis zum 23. Oktober arbeitete ich ungefähr vier Stunden pro Arbeitstag an dieser zweiten Phase, insgesamt rund 32 Stunden.

Ein Agent erstellt, ein anderer prüft und ein Mensch entscheidet

Interessant war auch, wie ich Entwicklung und Bereitstellung organisiert habe.

Statt einen Agenten für alles einzusetzen, erstellte ich mehrere Agenten mit klaren Aufgaben: Einer sollte die bisherige Implementierung untersuchen, ein anderer die bestehende Benutzeroberfläche auf der neuen Plattform nachbauen, weitere die Umsetzung überprüfen und einer die Bereitstellung übernehmen.

Außerdem erstellte ich wiederverwendbare Skills mit Anweisungen zu Bereitstellungsskripten, Tests und Validierung. So konnten die Agenten dieselben Abläufe befolgen, ohne dass ich jedes Mal alles von Grund auf erklären musste.

Diese Skills enthielten Anweisungen dazu, wie sich die Agenten in unserem Designsystem zurechtfinden, Design-Tokens wiederverwenden und mit den neu eingeführten Frameworks arbeiten sollten.

Warum Skills? Weil sie es Agenten ermöglichen, dasselbe Wissen und dieselben Anweisungen wiederzuverwenden, ohne für jede einzelne Aufgabe zu viele hoch spezialisierte Agenten erstellen zu müssen.

Bei Code-Reviews stützte ich mich stark auf Git-Diffs und prüfte Änderungen auf doppelten Code, unnötige Komplexität und uneinheitliche Implementierungen. Sobald ich etwas fand, bat ich die Agenten, es zu beheben.

Da Next.js und Payload CMS bereits etablierte Architekturmuster vorgeben, wies ich die Agenten an, diesen Konventionen zu folgen, statt eine eigene Architektur zu erfinden.

Außerdem beauftragte ich separate Agenten mit der Prüfung der Implementierung.

Der Ablauf war ziemlich einfach:

Ein Agent erstellt, ein anderer prüft und ein Mensch entscheidet, was richtig oder falsch ist.

Und der Mensch achtet auf die tatsächliche Website, nicht nur auf den Code.

Wir prüften die Benutzeroberfläche manuell, sahen uns die Darstellung der Seiten an, testeten Komponenten und suchten nach visuellen Problemen, die bei einer reinen Codeprüfung möglicherweise nicht auffallen.

Etwa 30% meiner Zeit entfielen darauf, Code zu prüfen, Implementierungen zu kontrollieren und Ergebnisse zu validieren.

Vor der Bereitstellung führte ich zusätzliche Prüfungen durch Agenten ein, um verbleibende Probleme zu finden und Code aufzuräumen, der nach wiederholten Iterationen übrig geblieben war.

Denn KI erzeugt Unmengen an Code.

Und wenn niemand genau hinschaut, ersetzt man leicht die alten technischen Schulden durch neue.

Die Website mit KI-Agenten übersetzen

Ein weiterer wichtiger Teil der Umsetzung waren die Übersetzungen.

Zuvor hatten wir GTranslate genutzt, um unsere Inhalte in Echtzeit zu übersetzen.

Diesmal sollten die Übersetzungen direkt in unserer Plattform verwaltet werden.

Ein KI-Agent übersetzte unsere englischen Inhalte in alle anderen Sprachversionen der Website.

Der Prompt lautete:

Du übersetzt Inhalte aus dem Englischen in die [Zielsprache].

Analysiere die englische Fassung der Inhalte und identifiziere Markennamen, technologiespezifische Begriffe, Produktnamen und andere Eigennamen.

Stelle vor der Übersetzung sicher, dass du die ursprüngliche Absicht und die genaue Bedeutung der Inhalte verstanden hast. Halte die Übersetzung so nah wie möglich an der ursprünglichen Bedeutung und Absicht und beachte dabei die natürlichen Sprachregeln der [Zielsprache].

Behalte Markennamen, Produktnamen und technologiespezifische Terminologie bei, wo dies angemessen ist.

Prüfe nach der Übersetzung, ob die Bedeutung erhalten geblieben ist, die Sprache natürlich klingt und keine Inhalte ausgelassen wurden.

Übersetze sämtliche Inhalte, einschließlich des Artikeltitels, der Überschriften, des Fließtexts und aller zugehörigen Metadaten.

Es ging nicht nur darum, Wörter zu übersetzen. Die Inhalte sollten den Regeln der jeweiligen Sprache folgen und für Menschen vor Ort natürlich klingen.

Außerdem trennten wir markenspezifische Angaben von übersetzbaren Inhalten, damit Firmennamen, Produktnamen und andere wichtige Begriffe nicht falsch übersetzt würden.

Jetzt können wir Übersetzungen direkt in unserem CMS verwalten, ohne von einem Plugin abhängig zu sein, das alles in Echtzeit übersetzt.

Natürlich sind KI-Übersetzungen nicht perfekt, gerade bei technischen Inhalten über Salesforce, CRM und Softwareentwicklung.

Wenn Sie unsere Website in Ihrer Sprache besuchen und bemerken, dass etwas unnatürlich klingt, schlecht formuliert ist oder keinen Sinn ergibt, schicken Sie mir einfach eine Direktnachricht.

Ich kümmere mich darum.

Als Figma, Codex und GPT-6 zusammenkamen

In der Zwischenzeit stellte unser Designer das neue Designsystem in Figma fertig. Ab da wurde es interessant.

Figma unterstützt die MCP-Integration und wir nutzen OpenAI bereits mit Salesforce und anderen Plattformen. Also verband ich Figma mit meinem OpenAI-Konto.

So konnte ich den Link zu einem Figma-Knoten – etwa einem Button, einem Abschnitt oder einer anderen Komponente – an Codex mit GPT-6 weitergeben. Codex übernahm den Entwurf und setzte ihn direkt auf unserer Website um.

Dank der Vorarbeit beim Herauslösen wiederverwendbarer Komponenten konnte es das neue Designsystem seitenübergreifend anwenden, statt dieselben Änderungen überall einzeln umzusetzen. Statt CSS manuell zu schreiben und jeden Innenabstand, Eckenradius oder jedes Komponentenlayout anzupassen, konnte ich die Figma-Entwürfe unseres Designers in der Codebasis umsetzen lassen.

Natürlich lief das nicht vollständig automatisch. Ich musste weiterhin den Code, die HTML-Struktur, das Verhalten der Komponenten und die Stellen prüfen, an denen OpenAI möglicherweise Abkürzungen genommen oder Anforderungen missverstanden hatte.

Im Durchschnitt brauchte jede Komponente ungefähr zwei Iterationen.

Darauf richtete ich den größten Teil meiner Aufmerksamkeit.

Was wir tatsächlich erreicht haben

Mit der neuen Node.js-Implementierung, Caching, serverseitigem Rendering und weiteren Optimierungen laden Seiten jetzt im Durchschnitt in unter einer Sekunde – verglichen mit ungefähr fünf oder sechs Sekunden vor dem Umbau.

Wir betrachteten Performance-Kennzahlen im Browser, darunter das Rendering der Seiten, Largest Contentful Paint und Layout-Verschiebungen. Mit Semrush-Audits bewerteten wir den technischen Zustand der Website, die Crawlbarkeit, die Navigation und weitere technische Aspekte.

Ich beurteilte die Performance aber auch auf viel einfachere Weise.

Bei der alten Website konnte ich die Verzögerungen auf Mobilgeräten wie am Desktop tatsächlich sehen. Die Seiten brauchten Zeit zum Laden und die Nutzung war nicht besonders angenehm.

Bei der neuen Implementierung war der Unterschied sofort spürbar.

Die Website fühlt sich einfach deutlich schneller an.

Natürlich ersetzt der visuelle Eindruck keine technischen Messungen. Für mich war er aber ein wichtiger Indikator, weil genau das die Besucher erleben.

Eine weitere wichtige Verbesserung war die Zahl der technischen Probleme.

Im September und Oktober meldete Semrush ungefähr 2.000 Probleme, mit Spitzenwerten von fast 3.000.

Jetzt liegen wir bei ungefähr 400 Problemen. Etwa 200 davon hängen mit dem E-Mail-Schutz von Cloudflare zusammen, den Semrush als defekte interne Links meldet.

Es gibt noch einiges zu verbessern, aber im Vergleich zum Ausgangspunkt ist die Situation eine völlig andere.

Von der Website-Wartung zu Inhalten direkt für Kunden

Die Performance war nicht die einzige Verbesserung.

Wir erreichten auch etwas, das wahrscheinlich noch wichtiger ist: eine wesentlich angenehmere Möglichkeit, Inhalte zu erstellen und zu verwalten.

Früher musste für eine Seitenänderung jemand manuell Vorlagen aktualisieren, Inhalte anpassen und die technischen Arbeiten erledigen.

Statt mehrere Personen einzubeziehen, um unsere Erfahrungen in Website-Inhalte zu verwandeln, können wir den Großteil der Routinearbeit über die Plattform abwickeln.

Der Entwickler muss kein Texter werden. Der Kundenbetreuer muss kein Entwickler werden. Und wer eine Idee hat, sollte nicht monatelang darauf warten müssen, dass sie jemand auf der Website umsetzt.

Das heißt auch nicht, belanglose KI-Massenware zu erzeugen.

Nehmen wir diesen Artikel als Beispiel.

Er wird nicht von Hand geschrieben. Die Ideen und Gedanken werden diktiert, in Text transkribiert und anschließend überarbeitet.

Wir können zum Beispiel sagen: „Formuliere das um, lass diesen Teil besser klingen, entferne unnötige Wörter, drücke dich höflicher aus.“

Aber die Ideen, Erfahrungen und die Geschichte stammen weiterhin von uns.

KI hilft uns, unsere Gedanken in lesbaren Text zu verwandeln – so wie sie dabei geholfen hat, unsere Designvorgaben und technischen Anforderungen in funktionierenden Code umzusetzen.

Genau diesen Arbeitsablauf wollten wir.

Derselbe Ansatz eignet sich für technische Artikel, Kundenerfolgsgeschichten, Leistungsbeschreibungen und andere Inhalte, die wir teilen möchten.

Früher verließen wir uns stark auf Texter und Website-Administratoren, um aus wenigen Worten technischer Experten vollständige Artikel zu machen.

Ein technischer Experte erklärt in wenigen Minuten, was er gemacht hat, und ein Texter macht daraus Tausende Wörter.

Große, selbstbewusste Artikel mit viel Text, Erklärungen und häufig auch viel heißer Luft.

Der Entwickler selbst würde dasselbe Projekt wahrscheinlich in wenigen Sätzen beschreiben:

„Ja, wir haben das gemacht. Es war einfach. Es war interessant. Es hat Spaß gemacht.“

Vielleicht erwähnt er nebenbei noch einige geschäftliche Vorteile. Obwohl ein Kundenbetreuer diese wahrscheinlich viel besser erklären können sollte.

Wir möchten, dass unsere Entwickler kurz erklären, was an der Umsetzung interessant war, was technisch anspruchsvoll war und was nützlich war – und sich dann wieder anderen interessanten Aufgaben widmen.

Statt jemandem stundenlang alles zu beschreiben, der daraus irgendwann einen Artikel macht.

Genau diese Routine wollten wir abschaffen.

Und genau das meine ich damit, die Leistungserbringung näher an den Kunden zu bringen.

KI kann helfen, die Routinearbeit zwischen diesen Menschen zu reduzieren, damit Wissen viel direkter von denen, die es besitzen, zu denen gelangt, die es brauchen.

Entwicklungsaufwand und Kosten

Das bedeutet natürlich nicht, dass die Website für insgesamt €245 neu aufgebaut wurde.

Darin sind weder meine Zeit noch die Arbeit unseres Designers, die Infrastruktur oder die Investitionen der vergangenen Jahre enthalten.

Seit 2019 entwickeln und verbessern wir unsere Website: Wir wechseln Themes, aktualisieren Designs, erstellen Inhalte und passen die Struktur an.

Bei der jüngsten Migration konnten wir einen großen Teil dieser Arbeit wiederverwenden.

Interessant ist aber, wie viel ich in ungefähr 60 Stunden eigener Mitarbeit erreichen konnte – mit KI für Entwicklung, Refactoring, Tests, Bereitstellung und Code-Reviews.

Was sich in der Praxis verändert hat

Der folgende Vergleich bezieht sich auf die verstrichene Umsetzungszeit bei der Zusammenarbeit mit einem freiberuflichen Entwickler. Er ist weder ein Budgetvergleich noch ein direkter Vergleich der geleisteten Arbeitsstunden.

Beispielsweise kann eine Seite ungefähr 40 Stunden Entwicklungsarbeit erfordern, die sich über mehrere Wochen und laufende Verbesserungen verteilen.

Diese Schätzungen beginnen, nachdem Idee und Anforderungen feststehen. Ideenentwicklung und Anforderungsdefinition sind eigenständige, wichtige Phasen und hier nicht enthalten.

Wie geht es weiter?

Die technische Grundlage steht jetzt.

Wir haben eine Plattform, die wir pflegen können, ohne jede einzelne Änderung auf der Website manuell vornehmen zu müssen.

Natürlich können wir weiterhin alles direkt bearbeiten, wenn wir möchten. Jetzt können wir aber auch einfach dem Agenten, der unsere Website betreut, sagen:

Ergänze [Artikel], verwende [Bilder], erstelle aus diesen Inhalten einige Infografiken oder Tabellen und veröffentliche sie als [Fallstudie oder Blogartikel].

Dasselbe gilt für die Aktualisierung bestehender Seiten.

Zum Beispiel:

Nimm diese Seite [URL oder Seitentitel angeben], finde diesen Abschnitt [Abschnittsname, Überschrift oder ID angeben], aktualisiere ihn. Ersetze das Bild, aktualisiere oder ergänze den Text gemäß meinen Anweisungen und stelle sicher, dass alles unserem bestehenden Designsystem folgt. Bewahre die Funktionalität der Komponente und überprüfe die Änderungen.

Ob wir ein Bild ersetzen, eine Leistungsbeschreibung ergänzen, einen Artikel veröffentlichen oder einen ganzen Abschnitt aktualisieren möchten: Wir können erklären, was wir erreichen wollen, das Ergebnis prüfen und es bei Bedarf anpassen.

Das spart Stunden an Routinearbeit, die wir in neue Ideen, die Erforschung von Kundenbedürfnissen und nützliche Inhalte investieren können.

Und ja, die Situation ist jetzt aus so ziemlich jeder Perspektive deutlich besser.

Die Infrastruktur steht. Die Plattform lässt sich einfach warten. Man muss nur formulieren, was man braucht, und der Agent kann es in wenigen Minuten ergänzen. Inhalte lassen sich leichter veröffentlichen und wir haben viel mehr Kontrolle darüber, wie die Website funktioniert.

Jetzt können wir uns auf Ideen statt auf technische Einzelheiten konzentrieren.

Die wichtigere Veränderung betrifft aber die Zusammenarbeit mit unseren Kunden.

Statt Entwickler, Kundenbetreuer, Marketing und Website-Administratoren durch zahlreiche Schritte und Prozesse voneinander zu trennen, können wir den Wissensaustausch viel direkter gestalten.

Die Menschen, die die Probleme der Kunden verstehen, können ihr Wissen weitergeben. Und diejenigen, die Lösungen entwickeln, erfahren direkt, was Kunden tatsächlich brauchen.

Technologie sollte nie das Problem sein, mit dessen Lösung wir die meiste Zeit verbringen.

Sie sollte uns helfen, unsere Ideen zu den Kunden zu bringen.

Und jetzt ist die Technik endlich kein Ärgernis mehr.