Ein KI-Baukasten liefert Ihnen in einem Nachmittag ein funktionierendes React-Frontend. Ein CMS gibt Ihrem Team etwas, das es am Montag bearbeiten kann. Die Lücke dazwischen kostete früher zwei Wochen Entwicklerzeit – und genau diese zwei Wochen lassen „eine Website an einem Tag“ nach einer Lüge klingen.
Ist sie nicht – aber nur, wenn Sie die Schritte in der richtigen Reihenfolge gehen und wissen, welche sich nicht beschleunigen lassen. Hier ist der komplette Weg, vom leeren Prompt bis zur Live-Website auf WordPress oder HubSpot, samt der Stellen, die übersprungen werden.
Derselbe Weg funktioniert an beiden Enden des Marktes, aber es lohnt sich, genau zu sagen, was er spart – denn die Antwort fällt je nach Ende unterschiedlich aus.
Für kleine und mittlere Unternehmen war der Bau das, was eine individuelle Website unbezahlbar machte. Nicht das Design, nicht der Text – die zwei Wochen Entwicklerzeit zwischen „Design fertig“ und „bearbeitbar“. Fällt dieser Block weg, ist eine sauber gebaute, native Website keine Budgetfrage mehr. Danach gehört sie dem Marketing-Team: Überschriften ändern und neue Seiten anlegen sind Inhaltsaufgaben, keine Tickets – die Kosten kommen also nicht still über die Wartung zurück.
Für Konzernteams war die Beschränkung nie, sich Entwickler leisten zu können – sondern dass die Entwickler ausgebucht sind. Kampagnenseiten stehen wochenlang hinter Roadmap-Arbeit in der Schlange, und der Kampagnentermin verschiebt sich nicht, um in diese Schlange zu passen. Das nimmt den Bau vollständig aus dem Engineering-Backlog, und weil das Ergebnis ein natives Theme ist und keine Page-Builder-Schicht, beantwortet es die Governance-Fragen von IT und Marke gleich mit: kein zusätzliches Plugin im Stack, keine Lizenz zum Verlängern, keine fremde Rendering-Schicht zwischen Ihren Inhalten und Ihrem CMS.
Die ehrliche Einordnung in beiden Fällen: Weg fällt der mechanische Block – Markup in HubL oder Gutenberg neu bauen, jedes editierbare Feld verdrahten, Blog-Templates und Formulare nachbauen. Bei einer typischen Website ist das der Großteil der Stunden. Ein 300-Stunden-Projekt haben wir Zeile für Zeile aufgeschlüsselt, falls Sie die Rechnung sehen möchten. Strategie, Texte und Freigaben dauern weiterhin exakt so lange wie immer.
Die meisten Unternehmen prompten KI-Baukästen nicht selbst – und müssen es auch nicht. Häufiger ist, dass eine Freelancerin, ein Freelancer oder eine Designagentur das erste Konzept erstellt und der Rest daraus fertiggestellt wird. Wenn das Ihre Situation ist, kommt es nicht auf die Werkzeuge an, sondern darauf, wer was hält und wo Sie freigeben.
Die Freelancerin, der Freelancer oder die Agentur entwickelt die erste Idee in Figma. Nicht die ganze Website – das Konzept. Die visuelle Richtung, das Designsystem und genug Schlüsselseiten, um beides zu etablieren: eine Startseite, eine typische Inhaltsseite, die Komponenten, die sich wiederholen. Hier steckt das Denken, und dafür bezahlen Sie tatsächlich.
Die KI macht daraus die Website. Aus diesem Konzept baut ein KI-Baukasten die vollständige Website – die übrigen Seiten, die Zustände, die niemand gezeichnet hat, die Texte für Abschnitte, die nur als graue Box existierten. Er folgt dem Designsystem, das er bekommen hat, sodass die zwanzigste Seite zur ersten passt. Das ist die kommerziell entscheidende Veränderung: Sie beauftragen ein Konzept statt zwanzig Seitendesigns – und das sind sehr unterschiedliche Rechnungen.
Wenn das Design bereits fertig ist und Sie diesen Schritt überspringen möchten: Eine fertige Figma-Datei geht ohne Code-Zwischenschritt direkt in transjt. Beide Wege enden am selben Punkt.
transjt macht daraus eine echte Website in WordPress oder HubSpot: jede Seite, jeder wiederverwendbare Block, der Blog, die Formulare. Kein Bild einer Website und keine starre Vorlage – das echte Ding, in dem System, das Ihr Team ohnehin nutzt.
Danach übernimmt Ihr Team. Eine Überschrift ändern, ein Foto tauschen, die Kampagnenseite für das nächste Quartal anlegen: Das wird zur Aufgabe derjenigen, die die Texte schreiben – und nicht zu einer Anfrage, die sich in eine Entwicklungsschlange stellt.
Auf zwei Kontrollpunkten sollten Sie bestehen: die Design-Freigabe, bevor irgendetwas gebaut wird, und eine halbe Stunde im CMS danach – gemeinsam mit der Person, die die Website tatsächlich pflegen wird – um zu bestätigen, dass sie das bearbeiten kann, was ihr zugesagt wurde. Alles dazwischen ist Mechanik.
Welches CMS. Entscheiden Sie jetzt, nicht nach dem Bau. Es ändert nichts am Prototyping, aber es bestimmt, was Sie in Schritt 5 verbinden und wer Ihnen Zugriff geben muss. Falls Sie noch abwägen: Die praktischen Unterschiede behandeln wir separat – diese Anleitung funktioniert für beide identisch.
Die Stack-Vorgabe. Das ist die, die Tage ruiniert. Die meisten KI-Baukästen greifen standardmäßig zu Next.js mit Server Components, und weder WordPress noch HubSpot hat eine Node-Laufzeit, die auf eine Server-Schicht wartet. Sagen Sie es im Prompt, bevor Sie irgendetwas generieren: React mit Vite, client-seitiges Routing, kein SSR, keine Server Components. Es erst nach der Design-Freigabe zu entdecken, kostet einen Neubau.
Lovable, Bolt, v0, Claude Code, Replit, rocket, Figma Make – nehmen Sie, was Ihnen liegt. Der Konvertierung ist das egal. Worauf es ankommt, ist, wonach Sie fragen.
Drei Dinge, die Sie festlegen sollten, solange Sie noch prompten – weil sie nachzurüsten mehr kostet, als sie zu verlangen:
Planen Sie dafür den Vormittag ein. Es ist der einzige Schritt, bei dem das Denken bei Ihnen liegt – und der, für den sich die Stunden lohnen.
transjt liest das echte Projekt und nicht einen Screenshot davon – der Code muss also irgendwo liegen, wo er gelesen werden kann. Dieser Ort ist GitHub: Stellen Sie es sich als das gemeinsame Laufwerk vor, auf dem Code liegt. Die meisten KI-Baukästen schicken das Projekt mit einem Klick dorthin; falls Ihrer das nicht kann, erledigt Ihre Entwicklung oder Agentur das in wenigen Minuten.
Ist das Repository privat, ist das der Schritt, der still eine Stunde kostet: Laden Sie github.com/transjt ein oder teilen Sie einen Lesezugriff, bevor Sie weitermachen. Zwei Minuten Arbeit, die alles Nachfolgende blockieren.
Fügen Sie in transjt Ihr GitHub-Konto hinzu, wählen Sie das Repository und den Branch, den Sie gerade hochgeladen haben. Wählen Sie Ihr Ziel – WordPress oder HubSpot – und starten Sie die Konvertierung.
Die Vorschau läuft, bevor Sie sich festlegen. Das ist also der Moment zu prüfen, ob zurückkam, was Sie erwartet haben: die Seiten, die Sie gebaut haben, die Komponenten, die Sie benannt haben, die Inhalte, die Sie geschrieben haben.
Das ist der Teil, der früher die zwei Wochen war. Der Export läuft unbeaufsichtigt, und das fertige Theme liegt innerhalb von etwa zwei Stunden in Ihrem Account – kurz genug, um in den Arbeitstag zu passen und danach noch Zeit zum Prüfen zu lassen.
Was Sie bekommen, ist kein Code-Ordner, den noch jemand übersetzen muss. Es ist ein natives Theme: HubL-Module oder Gutenberg-Blöcke, die Seiten zusammengesetzt, jede wiederverwendbare Komponente als editierbares Modul, Blog-Templates verdrahtet und Formulare mit ihren Feldern bereits an Ort und Stelle.
Starten Sie ihn vor dem Mittagessen und machen Sie etwas anderes, während er läuft. Genau darum geht es bei diesem Schritt – er ist der einzige, der Sie nicht im Raum braucht.
Das Theme muss irgendwo landen, und dieses Irgendwo muss vorher eingerichtet sein. Bei HubSpot autorisieren Sie das Portal, auf das Sie ausspielen – und prüfen, ob Sie dort tatsächlich Veröffentlichungsrechte haben, denn in den meisten Unternehmen hat die jemand anderes. Bei WordPress installieren und aktivieren Sie das transjt-Plugin auf der Zielseite und stellen sicher, dass es auf dem aktuellen Stand ist; ein veraltetes Plugin ist die häufigste Ursache für einen Import, der nur halb funktioniert.
Zugriffsanfragen liegen in den Warteschlangen anderer Leute, und eine Warteschlange lässt sich nicht durch längeres Arbeiten verkürzen. Wenn Sie früh am Tag nur eine Sache tun, dann diese.
Öffnen Sie die Website jetzt im Editor des CMS und lesen Sie sie, wie eine Besucherin oder ein Besucher es täte. Sie prüfen dabei zwei verschiedene Dinge gleichzeitig.
Ist alles da? Jeder Abschnitt, jede Seite, die Blog-Übersicht und mindestens eine Blog-Detailseite. Was im Prototyp fehlte, fehlt auch hier.
Ist es dort editierbar, wo es das sein muss? Klicken Sie in die Module, die Ihr Marketing-Team wirklich ändern wird – Überschrift, Feature-Karten, Preiszeilen – und bestätigen Sie, dass es Felder sind und kein fester Text. Das ist auch der Moment, Seiten zu ergänzen, die es im Prototyp nie gab, mit den Komponenten, die Sie bereits haben. Das ist die Rendite darauf, es nativ zu machen: Eine neue Seite ist jetzt eine Inhaltsaufgabe.
Ein generiertes Frontend hat keinen Grund, von Ihrem CRM, Ihrer Analytics oder Ihrer Sichtbarkeit in Suchmaschinen zu wissen. Sechs Dinge zu verbinden, keines davon dauert lange:
Testen Sie auf einem echten Telefon, nicht in einem verkleinerten Browserfenster. Mehr als die Hälfte des Traffics an einem Launch-Tag kommt von dort, und ein Desktop-Fenster auf 375 px sagt Ihnen nicht, was ein echtes Gerät mit Ihrem Hero-Bereich macht.
Gehen Sie die Website dann durch wie eine Besucherin: jeden Navigationspunkt anklicken, jeden Button, jede Karte. Das Formular noch einmal absenden. Mit der Tastatur durchtabben, um zu prüfen, dass nichts unerreichbar ist. Und schauen Sie sich die größten Bilder an – ein Prototyp hat keinen Grund, sie optimiert zu haben, und ein Hero-Bild direkt aus einem KI-Baukasten wiegt oft mehrere Megabyte.
Veröffentlichen – und dann die drei Dinge tun, die übersprungen werden, weil der Tag vorbei ist: die Live-URL selbst öffnen und die wichtigste Aktion anklicken, die Sitemap in der Search Console einreichen und einen echten Formulareingang abwarten, bevor Sie den Laptop zuklappen.
Liegt die Website auf einer neuen Domain, ist die DNS-Änderung das Letzte, was wirklich nicht in Ihrer Hand liegt – starten Sie sie morgens zusammen mit den CMS-Zugriffen, nicht um sechs Uhr abends.
| Wann | Was passiert |
| Erste Stunde | CMS entscheiden. Portal-Zugriff anfragen oder das Plugin installieren. |
| Vormittag | Das Frontend im KI-Baukasten bauen, mit echten Inhalten auf jeder Seite und der Stack-Vorgabe von Anfang an. |
| Vor dem Mittag | Auf GitHub hochladen, Repository-Zugriff geben, in transjt verbinden und die Konvertierung starten. Sie läuft, während Sie essen. |
| Früher Nachmittag | Theme trifft ein. Im CMS-Editor prüfen: jeder Abschnitt da, das Richtige editierbar. |
| Mittlerer Nachmittag | Formulare ans CRM, Tracking, Metadaten, Favicon, Redirects. Das Formular komplett testen. |
| Später Nachmittag | Test auf echtem Gerät, komplett durchklicken, Bildgewicht prüfen. Reparieren, was bricht. |
| Tagesende | Veröffentlichen. Live-URL öffnen, Sitemap einreichen, einen echten Eingang abwarten. |
Das offen zu sagen, ist das, was den Rest des Plans trägt.
Eine Migration nicht. Eine bestehende Website umzuziehen bedeutet Redirect-Mapping, Content-Audits und das Erhalten von URLs – ein anderes Projekt mit anderer Form. Ebenso wenig eine Website aus einem Dutzend zustandsbehafteter Widgets: Wenn Ihr Prototyp in Wahrheit eine Anwendung ist, konvertieren Sie eine Anwendung, und das ist eine größere Aufgabe. Freigaben lassen sich auch nicht komprimieren – wenn drei Stakeholder zustimmen müssen, gehört der Kalender ihnen und nicht Ihnen. Und finale Texte kommen fast nie pünktlich; echte Worte haben nie die Länge, die das Design angenommen hat, rechnen Sie also mit kleinen Layout-Korrekturen, sobald sie da sind.
Was in einen Tag passt, ist der Bau. Und der war bis vor Kurzem genau der Teil, auf den alles andere gewartet hat.
Wenn Sie sehen möchten, was aus Ihrem eigenen Repository wird, bevor Sie sich festlegen: Die Konvertierung läuft zuerst als Vorschau – starten Sie bei KI zu Webseite. Und falls Sie das hier lesen, weil ein Termin gerade verschoben wurde: Das Playbook für dringende Projekte behandelt die Reihenfolge, wenn kein Spielraum bleibt.