Das Playbook für dringende Projekte: von Figma oder Vibe Code in zwei Tagen zum Live-CMS

Das Briefing, das freitags hereinkommt

Es beginnt meist gleich. Ein Kampagnentermin wurde verschoben. Eine Finanzierungsmeldung geht am Dienstag raus. Ein Wettbewerber hat etwas gelauncht, und jemand aus der Führungsebene möchte noch vor Wochenende eine Antwortseite online sehen. Und was tatsächlich existiert, ist eine Figma-Datei oder ein Lovable-Projekt, das jemand am Wochenende hochgezogen hat – und ein CMS, das mit beidem nichts anfangen kann.

Der Reflex in diesem Moment ist, sofort loszubauen. Genau dieser Reflex macht aus zwei Tagen fünf. Dringende Projekte scheitern viel häufiger an der Reihenfolge als am Aufwand – die Stunden werden investiert, nur in die falschen Dinge, in der falschen Reihenfolge, und was den Launch tatsächlich blockiert, entdeckt man am letzten Nachmittag.

Das ist die Reihenfolge, die funktioniert – egal ob Sie mit einer Design-Datei oder mit generiertem Code starten.

Zuerst: Klären Sie, welche Art von dringend Sie vor sich haben

„Dringend“ meint drei verschiedene Projekte mit drei verschiedenen Definitionen von fertig, und sie zu verwechseln ist der teuerste Fehler im ganzen Prozess. Bevor irgendetwas anderes passiert: Benennen Sie, in welchem Fall Sie sind.

Die Falle ist, einen Pitch wie einen Launch zu behandeln. Eine Demo braucht überhaupt kein CMS, und eines zu bauen kostet Sie den Tag, den Sie für die Pitch-Dramaturgie gebraucht hätten. Die umgekehrte Falle ist schlimmer: einen Launch wie eine Demo zu behandeln, etwas auszuliefern, das das Marketing nicht bearbeiten kann – und danach ein halbes Jahr lang jede Textänderung per E-Mail zu erledigen.

Wenn es ein echter Launch ist, ist der Rest dieses Artikels für Sie. Wenn es eine Demo ist: aufhören zu lesen, den Figma-Prototyp abfotografieren und proben gehen.

Die Stunde, die Sie nicht überspringen dürfen

Bevor eine einzige Komponente konvertiert wird, notieren Sie drei Dinge. Das dauert eine Stunde – und es ist die Stunde, die das Projekt rettet.

Erstens: die Seitenliste, priorisiert. Nicht „die Website“, sondern die tatsächlichen Seiten, in der Reihenfolge, in der sie existieren müssen. Die meisten dringenden Launches brauchen eine Seite. Erstaunlich viele brauchen eine Seite und eine Danke-Seite. Wenn Ihre Liste elf Einträge hat, ist nicht die Deadline das Problem, sondern der Umfang.

Zweitens: Wer pflegt die Seite nach dem Launch, und was wird geändert? Davon hängt ab, ob Sie echte CMS-Module brauchen oder ob hartcodiertes HTML überleben würde. Lautet die Antwort „Das Marketing tauscht wöchentlich die Überschrift und die drei Feature-Karten“, brauchen Sie editierbare Komponenten – und diese Anforderung muss von Anfang an sichtbar sein, statt am zweiten Tag nachgerüstet zu werden.

Drittens: die Abhängigkeit, die Sie nicht kontrollieren. Jeder dringende Launch hat eine Sache, die außerhalb Ihrer eigenen Tastatur liegt – Veröffentlichungsrechte im CMS, eine Domain- oder DNS-Änderung, ein Tracking-Container, der jemand anderem gehört, eine rechtliche oder markenseitige Freigabe. So etwas hat Warteschlangen, und eine Warteschlange lässt sich nicht durch längeres Arbeiten verkürzen. Finden Sie sie in der ersten Stunde und bringen Sie sie noch am selben Vormittag ins Rollen, denn es ist der einzige Punkt auf der Liste, bei dem Aufwand nicht hilft.

Wenn Ihr Ausgangspunkt Figma ist

Ob sich eine Figma-Datei gut oder schlecht konvertieren lässt, hängt fast ausschließlich an Entscheidungen, die vor Ihrer Ankunft getroffen wurden. Sie können das Designsystem eines anderen nicht unter Zeitdruck umbauen – aber Sie können vierzig Minuten in die Handvoll Dinge stecken, die die Ergebnisqualität wirklich bestimmen.

Das sollten Sie korrigieren – es verändert das Ergebnis

• Auto Layout überall dort, wo etwas responsiv sein soll. Absolut positionierte Frames werden zu festen Kästen. Ein Abschnitt mit Auto Layout wird zu etwas, das umbricht. Das ist die wirkungsvollste Korrektur in einer Figma-Datei, und bei einer Landingpage sind es meist fünf oder sechs Frames.
• Wiederkehrendes einheitlich benennen. Heißen drei Karten „Card“, „Card 2“ und „Frame 481“, werden sie als drei unabhängige Blöcke gelesen statt als eine wiederholbare Komponente. Das Umbenennen dauert zwei Minuten und macht aus drei Einzelblöcken ein editierbares Modul mit drei Einträgen.
• Dekoratives Durcheinander flachziehen. Zwölf gestapelte Vektorebenen, die eine Hintergrundverzierung ergeben, sollten ein exportiertes Bild sein. In verschachtelter Vektorsuppe sterben Konvertierungszeit und Seitengewicht gleichermaßen.
• Echte Textstile verwenden, keine Overrides. Hat jede Überschrift eine manuelle Größe, hat das Ergebnis kein typografisches System – und jede künftige Änderung ist ebenfalls Handarbeit.

Das können Sie sich sparen

• Hover-Zustände, die als eigene Frames gezeichnet sind. Notieren Sie sie in einem Kommentar und ergänzen Sie sie hinterher in CSS; jeden Zustand zu zeichnen kostet Stunden und konvertiert zu nichts.
• Die Seiten zwei bis acht der Datei. Konvertieren Sie die Seite, die Sie launchen. Der Rest ist Umfang, nach dem noch niemand gefragt hat.

Wenn Ihr Ausgangspunkt Vibe Code ist

Lovable, Bolt, v0, Claude Code, Figma Make, Google Stitch – die Ergebnisse unterscheiden sich im Stil, nicht in der Art. Sie bekommen ein funktionierendes React-Frontend, meist ansehnlich, meist responsiv – und strukturell fremd sowohl für WordPress als auch für HubSpot. Diese Lücke ist kein Fehler des Werkzeugs. Diese Werkzeuge wurden gebaut, um eine Anwendung zu erzeugen, und Sie brauchen ein Theme.

Unter Zeitdruck verursachen drei konkrete Eigenschaften generierten Codes fast den gesamten Schmerz.

Inhalte, die im Komponentencode festgeschweißt sind

Generierter Code schreibt Ihre Überschrift direkt ins JSX. Für einen Prototyp ist das in Ordnung und für ein CMS fatal, denn jeder String, der im Code lebt, ist ein String, den das Marketing nicht ändern kann. Die Konvertierung muss diesen Text herauslösen und in ein Feld verwandeln – und je sauberer Struktur und Text im Original getrennt sind, desto besser gelingt das.

Zustand, wo Markup stehen sollte

Ein Akkordeon, das als React-State gebaut ist, wird im CMS-Theme entweder zu einem kleinen Stück Vanilla-JavaScript oder zu einem nativen details-Element. Ein Karussell wird zur Karussell-Bibliothek, die das Theme ohnehin lädt. Nichts davon ist schwierig – aber wenn Ihre Seite aus einem Dutzend zustandsbehafteter Widgets besteht, konvertieren Sie eine Anwendung, und das ist eine andere Größenordnung. Bei zwei Tagen Deadline streichen Sie die interaktiven Extras vorher, nicht hinterher.

Styling, das einen Build-Schritt voraussetzt

Tailwind-Klassen, CSS-in-JS und Komponentenbibliotheken setzen alle voraus, dass zur Laufzeit ein Bundler bereitsteht. Ein CMS-Theme liefert schlichtes CSS aus. Das ist das mechanischste der drei Probleme und dasjenige, das Sie am wenigsten beunruhigen sollte – aber es ist der Grund, warum „einfach den Code reinkopieren“ nie funktioniert, und das sollte man wissen, bevor man es einem Kunden verspricht.

Das Projekt in einen konvertierbaren Zustand bringen

Praktisch heißt das eine Sache: Bringen Sie den Code in ein Repository. transjt liest von GitHub, der schnellste Weg von einem Vibe-Code-Prototyp zum CMS-Theme ist also: Projekt pushen, Repository verbinden und die Konvertierung den echten Quellcode lesen lassen statt eines Screenshots davon. Ist das Repository privat, laden Sie github.com/transjt ein oder teilen Sie einen Lesezugriff – dieser Schritt erwischt viele genau in dem Moment, in dem sie nicht warten können.

Wo eine automatisierte Konvertierung wirklich Tage spart

Hier die ehrliche Rechnung. Die Arbeit zwischen „wir haben ein Design oder einen Prototyp“ und „das Marketing kann das in HubSpot oder WordPress bearbeiten“ zerfällt in etwa vier Blöcke:

• Markup und CSS in der Sprache des CMS neu bauen – HubL-Module oder Gutenberg-Blöcke
• Entscheiden, welche Teile editierbare Felder werden, und jedes einzelne verdrahten
• Das Drumherum neu bauen: Blog-Templates, Formulare, globaler Header und Footer
• Responsives Verhalten, Barrierefreiheit und der lange Schwanz kleiner Korrekturen

Die ersten drei sind mechanisch, und bei einer typischen Landingpage machen sie den Großteil der Stunden aus – von Hand durchgearbeitet genau dann, wenn Sie keine Entwicklungskapazität übrig haben. Genau das automatisiert transjt: Sie richten es auf die Figma-Datei oder das Repository, und es entsteht ein natives Theme mit Seiten, wiederverwendbaren Komponenten, Blog-Templates und Formularen, die bereits verdrahtet sind – statt eines Code-Ordners, den noch jemand übersetzen muss.

Die relevante Zahl für ein dringendes Projekt ist nicht, wie klug die Konvertierung ist, sondern dass der Export unbeaufsichtigt läuft und das fertige Theme innerhalb von etwa zwei Stunden in Ihrem Account liegt. Zwei Stunden sind kurz genug, dass sie in einen Arbeitstag passen und danach noch Zeit zum Prüfen bleibt – womit die Konvertierung aufhört, das zu sein, worauf die Deadline wartet, und die Deadline wieder von Inhalten und Freigaben handelt, wo sie hingehört.

Was sie nicht leistet, ist den vierten Block zu erfinden. Jemand prüft weiterhin das responsive Verhalten, kontrolliert weiterhin, ob das Formular tatsächlich ins CRM schreibt, und liest die Seite weiterhin auf einem echten Telefon. Planen Sie das ein. Es sind ein paar Stunden, nicht ein paar Tage – aber es ist nicht null, und jeder Plan, der null annimmt, ist der Plan, der kippt.

Ein realistischer Zwei-Tage-Ablauf

Angenommen, das Briefing kommt Donnerstagvormittag und die Seite muss Freitagabend live sein. So sieht eine Version aus, die tatsächlich funktioniert.

Beachten Sie, was bewusst fehlt: Es gibt keinen Block namens „Theme bauen“. Genau dieser Block hat früher beide Tage verschlungen, und ihn in ein unbeaufsichtigtes Zwei-Stunden-Fenster zu verschieben, macht den Rest des Plans überhaupt erst überlebbar.

Die zwei Dinge, die tatsächlich kippen

Fragen Sie jemanden, der einen dringenden Launch verpasst hat, was schiefging – fast niemand nennt den Bau. Genannt wird: Der Text war nicht fertig, oder die Freigabe kam Freitag um sechs mit drei Änderungen zurück.

Text. Platzhaltertext verbirgt das Problem bis zum letztmöglichen Moment. Eine Überschrift, die in einem Design-Frame funktioniert, ist nicht dieselbe Überschrift, sobald sie über einem echten Absatz steht – und echter Text hat nie die Länge, die das Design angenommen hat. Setzen Sie die tatsächlichen Worte Freitagvormittag ein, nicht Freitagnachmittag, und rechnen Sie danach mit kleinen Layout-Korrekturen. Das ist normal und deutlich billiger, als es eine Stunde vor dem Launch festzustellen.

Freigaben. Die Abnahme ist kein Schritt, sie ist eine Warteschlange mit anderen Menschen darin. Benennen Sie in der ersten Stunde, wer freigibt, sagen Sie, wann die Seite bereitsteht und wann das Zeitfenster schließt, und schicken Sie früher etwas zum Reagieren, als es sich angenehm anfühlt. Wer die Seite am Launch-Tag um vier zum ersten Mal sieht, findet immer etwas – weil das der einzige Moment ist, den Sie ihm gegeben haben.

Beides sind Inhaltsprobleme, keine Bau-Probleme – und genau das ist das Argument dafür, den Bau zu automatisieren. Die Stunden, die Sie freischaufeln, sind genau die, die diese beiden brauchen, und diese beiden entscheiden, ob der Termin hält.

Vier Abkürzungen, die mehr kosten als sie sparen

Jedes dringende Projekt bietet dieselben Umwege an. Jeder sieht aus, als spare er einen Nachmittag; jeder holt sich später eine Woche zurück, meist von jemandem, der nicht im Raum war.

Den Prototyp in einem iframe einbetten. In zehn Minuten live – und unsichtbar für Suchmaschinen, kaputt auf dem Handy, nicht bearbeitbar. In achtzehn Monaten wird er immer noch da sein, weil den Austausch nie jemand einplant.

Einen Page Builder installieren, „nur für diese eine Seite“. Das Plugin geht nie wieder. Es bringt seine eigene Rendering-Schicht mit, sein eigenes Performance-Profil und seine eigene Lizenzverlängerung, und jede danach gebaute Seite erbt diese Abhängigkeit. WordPress und HubSpot haben beide eine native Inhaltsschicht; nutzen Sie sie.

Den Text hartcodieren, „weil wir ihn später editierbar machen können“. Später kommt nicht. Was kommt, ist eine Überschriftenänderung per E-Mail am Sonntag.

Eine offene Feedbackrunde starten. „Irgendwelche Gedanken?“ am Launch-Nachmittag lädt zu Gedanken ein. Legen Sie den Schlusspunkt fest, wenn Sie die Deadline festlegen – Änderungen bis zu einer genannten Uhrzeit, alles danach kommt auf die Liste für nächste Woche – und halten Sie das schriftlich fest, bevor sich jemand eine Meinung gebildet hat.

Was Sie am Ende übergeben

Ein dringendes Projekt ist fertig, wenn jemand anderes es weitertragen kann – nicht, wenn es rendert. Zwei Dinge sollten zutreffen, bevor Sie den Laptop zuklappen.

Die Person, der die Seite gehört, kann den Text ohne Sie ändern. Wenn das Theme aus einer Konvertierung stammt, sind die Komponenten bereits im Editor des CMS bearbeitbar – zeigen Sie eine Änderung vor, solange Sie noch da sind. Eine Fünf-Minuten-Demo verhindert vierzehn Tage E-Mail.

Und die Komponenten sind wiederverwendbar. Nicht der Ordnung halber, sondern weil das nächste dringende Briefing bereits entsteht – und eine Seite aus benannten, wiederverwendbaren Modulen macht die Folgekampagne zu einer Inhaltsaufgabe statt zu einem weiteren Bau. Das ist die Rendite darauf, es beim ersten Mal nativ zu machen, und es ist das Argument gegenüber demjenigen, der zahlt.

Wenn die Deadline morgen früh ist

• Eine Seite. Keine Website. Setzen Sie das jetzt durch, nicht um Mitternacht.
• Die Konvertierung vor allem anderen starten, damit sie läuft, während Sie am Inhalt arbeiten.
• Sicherstellen, dass Sie tatsächlich veröffentlichen können – Zugriff, Domain, Freigabe – bevor Sie irgendetwas bauen.
• Echter Text schlägt perfektes Layout. Die richtigen Worte mit unsauberem Abstand konvertieren; umgekehrt nicht.
• Auf dem eigenen Telefon prüfen, bevor Sie jemandem sagen, dass es fertig ist.

Das Muster darunter passt in einen Satz: Bei einem dringenden Projekt ist nicht die Zeit knapp, sondern die Aufmerksamkeit. Alles Mechanische, das ohne Sie laufen kann, sollte ohne Sie laufen – und die Stunden, die Sie behalten, gehören den Entscheidungen, die nur ein Mensch treffen kann: was die Seite sagt, für wen sie da ist und wer Ja sagen muss, bevor sie online geht.

Wenn Sie sehen möchten, was aus Ihrer eigenen Datei oder Ihrem Repository wird, bevor Sie sich festlegen: Die Konvertierung läuft zuerst als Vorschau. Starten Sie mit einem Design über Figma zu HubSpot oder Figma zu WordPress, oder mit generiertem Code über KI zu Webseite.