Dann vs. Jetzt
Gleicher Scope. Andere Arbeitsweise. Anderes Ergebnis.
Wie ein klassischer Relaunch funktionierte
Bevor ich erkläre, was wir gemacht haben, lohnt sich ein kurzer Blick zurück. Der Relaunch 2021 war kein Ausreißer, nicht in der Qualität, sondern im Vorgehen und Aufwand. Er war der Standard. Zwei Agenturen, ein Freelancer, interne Stakeholder aus mehreren Bereichen, Workshops zu User Journeys, externe Redaktion, Wireframing, Design, CMS-Implementierung, Abnahmerunden. Jede Änderung lief über externe Briefings. Jede Iteration brauchte Wartezeit. Das Marketing-Team hatte verzögerten Einfluss auf das Ergebnis.
Man wusste, was man wollte, doch zuerst musste man es in ein Briefing übersetzen, auf dessen Basis jemand anderes dann einen Design-Entwurf erstellte. Stille Post, im besten Fall. Und Agenturen beschweren sich ja nicht zu Unrecht, dass Kunden oft nicht genau briefen können. Ich kenne das selbst: Manchmal kann man es schlicht nicht so in Worte fassen, welches Bild man vor Augen hat.
Das ist keine Kritik an der damaligen Entscheidung. Das war schlicht der Weg, den man ging, wenn man eine professionelle Website wollte. Rückblickend spannend zu sehen, wie AI diesen Weg verändert.
Ein Projekt, ein gemeinsamer Kontext
Bevor wir eine einzige Seite geschrieben oder ein einziges Design gebaut haben, haben wir eine Woche investiert, die nach außen unsichtbar ist. Man sieht in dieser Woche noch nichts. Aber ohne sie wäre alles danach langsamer gewesen.
Ich war als AI Enablement Managerin mit im Team, um diesen Relaunch so weit wie möglich AI-fähig zu machen. Die richtigen Tools aussuchen, das Team befähigen, mit AI zu arbeiten, gemeinsam die ersten Schritte gehen. Die ersten drei Wochen haben wir intensiv zusammengearbeitet.
Was in dieser Woche passiert ist: Parallel zur internen Arbeit haben wir mit AI und dem Vorstand die strategische Grundlage gelegt: Positionierung schärfen, Vision und Mission formulieren, die zentralen Aussagen der neuen Website herausarbeiten. Viel Arbeit, wenig sichtbares Ergebnis. Aber genau diese Klarheit hat später dafür gesorgt, dass die Agenten gute Outputs geliefert haben. Garbage in, garbage out gilt auch hier.
Gleichzeitig mussten alle Beteiligten auf einen Stand gebracht werden: Wie baut man einen Agenten? Wofür nutzen wir welchen? Wer ist Owner, wer Nutzer? Was brauchen wir bis wann, damit wir danach wirklich parallel arbeiten können, ohne gegenseitige Abhängigkeiten aufzubauen? Das sind keine spannenden Fragen. Aber sie zu klären, bevor man loslegt, ist der Unterschied zwischen einem Projekt, das läuft, und einem, das ständig ins Stocken gerät.
Und ich sage das bewusst: Die erste Woche war Orientierung. Für alle. Auch für mich. Niemand hat in dieser Woche eine fertige Seite gebaut. Aber ohne diese Woche wäre in den fünf danach deutlich weniger entstanden.
Erst danach haben wir das Langdock-Projekt als gemeinsamen Arbeitsraum angelegt. Geteilte Instruktionen, die für jeden Chat automatisch gelten. Geteilte Dokumente, die einmal hochgeladen und dann in jedem Chat verfügbar sind. Volle Transparenz: Jede Konversation, die wir einzeln geführt hatten, konnte jeder im Team sehen. Kein doppeltes Briefing, kein Kontextverlust.
Das war die Basis. Von diesem gemeinsamen Hub aus haben wir maßgeschneiderte Langdock-Agenten gebaut.
Die fünf Agenten im Projekt
Management-Input direkt in Positionierungspapier, Sitemap und Navigation. Gebaut von unserer Marketing-Leitung.
Echte Produkt-Screenshots in saubere, moderne UI-Mockups: minimalistisch, professionell, konsistent im Corporate Design.
Produktwissen gebündelt und für das gesamte Team abrufbar. Wer eine Seite schrieb, musste nicht erst intern nachfragen.
Erste Textentwürfe für alle Seiten. Gebaut von unserer Content Managerin. Erster Entwurf in Minuten statt Tagen.
Produktionsreife HTML/CSS/JS-Blöcke im Xempus Corporate Design, direkt einbettbar in WordPress.
Die Agenten haben nicht nur Arbeit abgenommen. Sie haben Wissen verteilt. Ein konkretes Beispiel: Für eine bestimmte Seite haben wir zuerst mit dem Strategie-Agenten gearbeitet, Positionierung durchdacht, Argumente strukturiert. Den Output haben wir dann direkt in den Texter-Agenten gegeben. Das Ergebnis war ein erster Textentwurf, der inhaltlich bereits auf dem richtigen Stand war, weil der Kontext nicht verloren gegangen ist. Kein Briefing, kein Übergabegespräch.
Warum wir nicht den einfachen Weg gegangen sind
Als wir das Projekt gestartet haben, haben wir zuerst mit unserem WordPress-Partner gesprochen. Die Einschätzung war klar: Was ihr da wollt, ist ein Porsche. Ihr habt aber nur Zeit und Budget für einen Fiat. Ihr Zeithorizont: drei Monate. Das war uns zu lang.
Und das war eine bewusste Entscheidung: Wir wollten dieses Projekt mit zwei Personen stemmen, die keine klassischen Tech-Profile haben. Keine Entwicklerin, kein Designer. Ein Marketing-Team, das bisher Agenturen gesteuert hat. Das war kein Versehen, das war der Plan. Wir wollten wissen, was heute mit AI möglich ist, wenn man nicht aus einem technischen Hintergrund kommt.
Wir hatten Langdock bereits als festen Tech Stack. Und wir hatten theoretisch Figma. Beim ersten Einloggen war schnell klar: Figma ist ein Profi-Werkzeug, das unsere UX-Abteilung täglich nutzt. Für uns, die wir es zum ersten Mal öffneten, war die Lernkurve zu steil für ein Projekt mit diesem Zeitdruck. Also haben wir weitergesucht und sind bei Lovable gelandet. Visuelles Prototyping, das sofort funktioniert, ohne Vorkenntnisse. Heute geht das übrigens auch hervorragend direkt in Claude über Artefakte, aber zum Zeitpunkt unseres Projektstarts war Lovable für uns der schnellste Weg.
Unseren WordPress-Partner haben wir früh eingebunden: Bereits in Woche zwei standen die ersten Prototypen, die wir mit dem Vorstand abgestimmt und dann zur Umsetzung übergeben haben. Der Auftrag: wiederverwendbare Gutenberg-Blöcke bauen, damit das Marketing-Team eigenständig Seiten aufbauen kann. Für komplexere Seiten war die Schätzung allerdings schnell klar: Der Nachbau als Blöcke wäre zu kostspielig und zu zeitintensiv gewesen. Also sind wir einen anderen Weg gegangen: Diese Seiten haben wir bis zum Schluss intern iteriert und dann als komplette HTML-Einbindungen direkt in WordPress eingefügt.
Zum Vergleich: Ein klassischer Website-Relaunch mit Agentur beginnt mit Wireframes, die die Agentur erstellt. Dann Feedback-Schleifen. Dann ein Prototyp, der wieder Feedback-Schleifen auslöst. Dann Design. Dann nochmal Abstimmung. Bis das erste Ergebnis sichtbar ist, sind Wochen vergangen. Mit Lovable haben wir diesen gesamten Prozess übersprungen. Wir hatten nach wenigen Stunden etwas Klickbares vor Augen, das wir sofort beurteilen, verändern und weiterentwickeln konnten.
Am Ende war auch unser WordPress-Partner beeindruckt. Ihr Kommentar: Wow, da habt ihr jetzt aber wirklich einen Porsche hingestellt. Was sie außerdem überrascht hat: dass man bei komplexen Seiten direkt mit HTML-Einbindungen arbeiten kann, statt alles in Gutenberg-Blöcke nachzubauen. Wir sind einen eigenen Weg gegangen, einen, den unser WordPress-Partner nicht vorgeschlagen hätte. Mit AI ist das möglich. Man muss es nur ausprobieren wollen.
Sechs Wochen. Nicht nacheinander, nebeneinander.
Iteration schlägt Perfektion. Parallelarbeit schlägt Wasserfall. Feedback ist kein Event, es läuft die ganze Zeit.
Die unsichtbare Woche. Keine Seite wurde gebaut. Stattdessen: strategische Grundlage mit AI und Vorstand, Positionierung schärfen, Agenten konzipieren, das Team einarbeiten. Wer diese Woche überspringt, zahlt sie später doppelt.
Das gemeinsame Langdock-Projekt geht live. Geteilte Instruktionen, geteilte Dokumente, volle Transparenz für alle Beteiligten. Die fünf Agenten werden gebaut, getestet und sofort intern reviewt. Parallel starten die Abstimmungsrunden mit den Produktmanagern. Die ersten Lovable-Prototypen werden mit dem Vorstand abgestimmt und anschließend an unseren WordPress-Partner übergeben, der daraus wiederverwendbare Gutenberg-Blöcke baut.
Figma war zu steil. Also Lovable. Innerhalb von Stunden: erste klickbare Prototypen. Kein Wireframing, kein Warten auf Feedback-Runden. Das Team sieht sofort, was gemeint ist, und gibt sofort Feedback. Erste Iteration noch am selben Tag. Die ersten Gutenberg-Blöcke stehen, das Marketing beginnt, eigenständig Seiten in WordPress zu bauen. Komplexere Seiten werden weiter in Lovable iteriert.
Der Web-Texter-Agent liefert erste Entwürfe. Der Mockup-Creator-Agent verarbeitet Produkt-Screenshots. Die Content Managerin überarbeitet, schärft, trifft den Ton, und baut parallel eigenständig weitere Seiten in WordPress. Komplexe Seiten bleiben in der internen Abstimmung: hier wird weiter iteriert, bis Inhalt und Design stimmen. Die Abstimmungen mit den Produktmanagern laufen weiter: fachliche Freigaben, inhaltliche Korrekturen, Detailfragen klären.
Die komplexen Seiten werden finalisiert und als vollständige HTML-Einbindungen direkt in WordPress eingefügt, weil der Nachbau als Gutenberg-Blöcke zu kostspielig gewesen wäre. Animierte Produkt-Mockups werden mit Claude Opus 4.6 direkt in Langdock programmiert und eingebettet. Unser WordPress-Partner begleitet den Go-Live. Finales Feedback der Produktmanager fließt ein. Go-Live im März 2026.
Der UX/UI-Designer-Agent hat technisch korrekte Outputs geliefert. Aber an rohem HTML zu iterieren ist langsam. Also haben wir gewechselt: zu Lovable. Nicht 1.000 Tools testen, sondern in den starken Werkzeugen, die bereits im Einsatz sind, echte Routinen aufbauen. Das ist es, was Menschen wirklich befähigt.
Wo die Grenzen lagen
Ich wäre nicht ehrlich, wenn ich das alles nur als Erfolgsgeschichte erzählen würde. Die finalen Texte kamen nicht von der KI. Am Ende sind wir selbstverständlich nochmal über alles drübergegangen, haben umformuliert, geschärft, den Ton getroffen. Die KI hat Rohstoff geliefert. Den Feinschliff hat ein Mensch gemacht. Das ist kein Makel. Das ist der Punkt.
Die animierten Produkt-Mockups auf der Website? Programmiert mit Claude Opus 4.6 direkt in Langdock. Kein externes Design-Studio, keine separate Produktionspipeline.
Warum wir nicht direkt aus Lovable live gegangen sind? Die Antwort ist pragmatisch: Lovable bietet kein garantiertes EU-Hosting: Die Plattform läuft auf AWS, ohne dass der genaue Serverstandort kontrollierbar ist. Für eine Produktions-Website mit DSGVO-Anforderungen ist das keine belastbare Grundlage. Außerdem ist Lovable kein CMS. Keine wiederverwendbaren Blöcke, keine nachhaltige Struktur für zukünftige Updates.
Aber es war nicht nur eine technische Entscheidung. Es war auch eine menschliche. Human im Fokus heißt auch: respektieren, wo die Grenzen liegen. Unsere Content Managerin sollte nicht von heute auf morgen für immer mit einem komplett neuen Tool arbeiten müssen. In diesem Projekt wurde bereits so viel mit AI gemacht, so viel Neues gelernt. Da war es der bessere Weg, für die Produktionsumgebung auf etwas zu setzen, das langfristig tragfähig ist. WordPress kennen wir. Darauf läuft alles sicher und stabil.
Und trotzdem war auch WordPress kein Selbstläufer. Früher gab es im Marketing-Team eine eigene Person, die WordPress bedient hat. Unsere Content Managerin hat es in diesem Ausmaß vorher nicht genutzt. Das heißt: Sie hatte nicht nur den AI-Sprung zu bewältigen, sondern parallel auch WordPress in einer Tiefe zu lernen, die vorher nicht nötig war. Und das alles in sechs Wochen, inklusive zahlreicher Abstimmungsrunden mit dem Produktteam. Das verdient Anerkennung.
WordPress mit Gutenberg-Blöcken gibt uns etwas, das beim letzten Relaunch nicht existierte: vollständige Autonomie nach dem Go-Live. Unsere Content Managerin kann heute eine neue Seite in unter 30 Minuten bauen. Ohne Entwickler, ohne Agentur-Briefing, ohne Wartezeit.
Und hier schließt sich ein Kreis zum alten Problem: Wer selbst prototypen kann, muss nicht mehr erklären, was er meint. Man kann der KI sagen, wie man es sich vorstellt. Man kann fragen: Wie könnte das aussehen? Mach mir mal Vorschläge. Und plötzlich hat man in Minuten etwas vor Augen, das man vorher in mühevollen Briefings zu beschreiben versucht hätte, ohne sicher zu sein, ob es am Ende so wird. Das macht einen großen Unterschied im Arbeitsalltag.
Die Zahlen, die zählen
Das ergibt: rund 7x schneller, rund 7x leaner, 93 Prozent Kosteneinsparung.
Und was ich für die Zukunft noch interessanter finde: Der nächste vergleichbare Relaunch würde uns schätzungsweise 3.000 Euro kosten. Weil die Blöcke stehen, die Agenten stehen, das Team weiß, wie es geht.
Was das mit AI Enablement zu tun hat
Ich war in diesem Projekt nicht die Person, die die meisten Seiten gebaut hat. Unsere Marketing-Leitung und unsere Content Managerin haben das Projekt getragen, neben ihrem laufenden Tagesgeschäft, mit begrenzter Kapazität. Meine Rolle als AI Enablement Managerin sah so aus: In den ersten zwei bis drei Wochen habe ich nicht nur den Workflow aufgesetzt, die richtigen Werkzeuge gefunden und das Team eingearbeitet. Ich habe auch selbst mitgearbeitet. Viel ausprobiert, viel getestet, um zu verstehen, was funktioniert und was nicht. Lovable ins Spiel gebracht. Eingeordnet, was der WordPress-Partner vorschlägt, und entschieden, welchen Weg wir stattdessen gehen. Das lag auch daran, dass ich selbst aus dem Marketing komme. Ich wollte das Team gerade am Anfang unterstützen, wo es darum ging, einen klaren Fahrplan zu entwickeln. Danach war das Team enabled und der Fahrplan stand. Ich habe mich den nächsten Bereichen gewidmet, die AI Enablement brauchten. Punktuell hatten wir Unterstützung: Ein Kollege mit Code- und UX-Erfahrung hat am Anfang und zum Schluss mitgeholfen, unser WordPress-Partner hat die Gutenberg-Blöcke gebaut und den Go-Live begleitet. Aber die tragende Arbeit lag bei zwei Personen aus dem Marketing.
Das meine ich mit AI Enablement. Nicht selbst alles machen. Sondern dafür sorgen, dass ein Team mit AI arbeiten kann, das vorher noch nie so gearbeitet hat. Und dann zusehen, wie es funktioniert.
Aber ich möchte an dieser Stelle ehrlich sein. Denn hinter diesem Satz steckt mehr, als er auf den ersten Blick zeigt. Mit AI kann man heute sehr viel. Die Frage ist nicht mehr, ob es technisch möglich ist. Die Frage ist: Will man das auch? Und wie viel Gewohntes ist man bereit loszulassen?
Was dieses Projekt von vielen anderen unterscheidet: Wir haben uns bewusst dafür entschieden, es so zu machen. Kein externes Team, keine Agentur für die Umsetzung, kein Entwickler im Lead. Zwei Personen mit Marketing- und Content-Hintergrund, die sich auf etwas eingelassen haben, das außerhalb ihrer bisherigen Komfortzone lag. Das braucht Mut. Und diesen Mut hatte das Team.
Wir sind in dieses Projekt mit Marketing- und Content-Skills gestartet. Wir sind herausgekommen mit Fähigkeiten, die wir vorher nicht hatten: Produktmockups mit AI coden, direkt in WordPress einbinden, ganze Seiten auf Basis eigener Prototypen bauen. Nicht ohne Reibung. Einbindungen sind gecrasht. Wir haben intern kurz nachgefragt, wenn wir nicht weiterkamen. Und dann hat es funktioniert. Das ist kein Scheitern, das ist Lernen unter echten Bedingungen.
Aber es kostet Energie. Und es braucht die Bereitschaft, sich auf diesen Weg einzulassen. Das war nicht immer bequem. Aber was dieses Team ausgezeichnet hat: Es hatte das richtige Mindset. Die Neugier, etwas auszuprobieren, das noch niemand so gemacht hat. Die Ausdauer, dranzubleiben, wenn es nicht sofort funktioniert. Und den Mut, einen Weg zu gehen, den unser WordPress-Partner nicht empfohlen hätte.
Dieses Mindset ist keine Selbstverständlichkeit. Und es ist oft der entscheidende Faktor, ob eine AI-Transformation funktioniert oder nicht.
Ich glaube, das ist der Punkt, den viele AI-Projekte übersehen: Man kann nicht einfach neue Werkzeuge einführen und erwarten, dass die Menschen mitgehen. Man muss auch fragen, was man ihnen dabei zumutet. Und ob der Mittelweg, den man findet, wirklich hält. Und dazu gehört auch: ehrlich einschätzen, was ein Team in welcher Zeit leisten kann. Nicht alles, was mit AI möglich ist, muss auch gemacht werden. Das ist keine Schwäche, das ist eine Entscheidung.
Wer ein Team durch eine AI-Transformation begleitet, muss auch die Frage stellen dürfen: Was wollen wir hier eigentlich erreichen? Und was brauchen die Menschen dafür, damit sie wirklich mitgehen, und nicht nur mitmachen, weil es erwartet wird? Das ist der psychologische Kern von AI Enablement, der in den meisten Playbooks fehlt.
„Am Anfang brauchte ich noch Orientierung, wo ich anfangen soll und was die KI überhaupt kann. Inzwischen bin ich vollständig enabled und sehe die Vorteile täglich in meiner Arbeit.“
Beide haben nicht nur ein Werkzeug gelernt. Sie haben gesehen, was möglich ist, wenn man aufhört zu warten, bis jemand anderes etwas fertig hat. Das ist der Unterschied, der bleibt. Nicht die 140.000 Euro Einsparung, so beeindruckend die Zahl auch ist.
Human in the lead
Was in diesem Projekt nicht zur Debatte stand: Die Menschen treffen die Entscheidungen. Die KI liefert Optionen, Entwürfe, Code, Vorschläge. Aber ob ein Text gut ist, ob ein Design stimmt, ob eine Seite das richtige Gefühl hat. Das hat am Ende ein Mensch entschieden.
Das klingt selbstverständlich. Ist es aber nicht, wenn man sieht, wie viele Teams entweder blind dem Output vertrauen oder so viel Angst vor der KI haben, dass sie gar nicht erst anfangen. Beides führt nicht weiter. Was funktioniert: KI als Werkzeug behandeln, das man führt. Nicht umgekehrt.
Human in the lead bedeutet: Menschen treffen die Entscheidungen, die KI liefert Optionen. Human im Fokus bedeutet: Der Mensch darf nicht aus dem Blick geraten, nur weil plötzlich so vieles neu möglich ist. Das ist nicht dasselbe.
AI-First arbeiten heißt nicht, dass der Mensch zurücktritt. Es bedeutet, dass der Mensch anders führt. Mit klareren Fragen. Mit mehr Urteilsvermögen. Mit der Fähigkeit, Output zu bewerten, statt ihn einfach zu übernehmen. Das ist anspruchsvoller, nicht einfacher. Und es braucht ein Mindset, das bereit ist, Kontrolle abzugeben, nicht aber die Verantwortung.
Was ich in diesen sechs Wochen gesehen habe: Aus Skepsis wird Neugier, wenn man den Raum gibt, wirklich auszuprobieren. Aus Neugier wird Stolz, wenn etwas funktioniert, das man sich vorher nicht zugetraut hätte. Das ist kein Automatismus. Das braucht Zeit, Begleitung und die Bereitschaft, Fehler als Teil des Prozesses zu akzeptieren.
Das ist es, was mich an AI Enablement antreibt. Nicht die Werkzeuge, nicht die Zahlen. Dieser Moment, in dem jemand merkt: Ich kann das. Die KI stärkt mich. Und es macht Spaß.
Was ich daraus für meine Arbeit mitnehme
Dieses Projekt hat mir gezeigt, wie viel in kurzer Zeit möglich ist, wenn drei Dinge zusammenkommen: ein gemeinsamer AI-Kontext für das gesamte Team, die richtigen Werkzeuge für die jeweilige Aufgabe, und ein Team, das bereit ist, sich auf etwas Neues einzulassen.
Was einen großen Unterschied gemacht hat, waren die Agenten. Nicht als Werkzeug im technischen Sinne, sondern als Wissenscontainer. Das Know-how einer Person, also wie man Xempus-Texte schreibt, wie das Design aussehen soll, wie die Produkte funktionieren, wurde einmal sauber in einen Agenten gegossen und stand dann dem gesamten Team zur Verfügung. Wissen, das sonst in einem Kopf sitzt, war plötzlich für alle nutzbar.
Das gilt übrigens nicht nur für Website-Projekte: Wenn jedes Produkt einen eigenen Agenten hat, der das Produktwissen bündelt, verändert sich, wie ein Team arbeitet. Nicht weil die KI klüger ist. Sondern weil das Wissen nicht mehr verloren geht.
Und noch etwas nehme ich mit: Das Lösungsdesign, das wir gewählt haben, war richtig für diesen Moment. Aber KI und die Werkzeuge drumherum entwickeln sich in einem Tempo weiter, das man nicht ignorieren kann. Selbst WordPress steht vor einem großen Sprung: Version 7.0, die im April 2026 erscheint, bringt Echtzeit-Kollaboration im Editor und native KI-Schnittstellen direkt im Core. Das hätte unseren Workflow an einigen Stellen verändert. Deshalb gehört es zu meinem Job, beim nächsten Projekt nicht einfach den gleichen Weg zu gehen, sondern neu zu schauen: Welche Werkzeuge gibt es jetzt? Was hat sich verändert? Was ist heute möglich, das vor sechs Monaten noch nicht da war? Das richtige Lösungsdesign ist eine Momentaufnahme.
Ähnliches Projekt vor dir?
Ich teile gern, was in diesem Projekt funktioniert hat und was nicht. Kein Sales-Pitch, kein Consulting-Angebot. Einfach Erfahrungen austauschen.
