Es fängt fast immer harmlos an. Jemand im Vertrieb baut sich an zwei Abenden mit Lovable oder Claude Code ein kleines Angebotstool, weil die Excel-Vorlage nervt. Es funktioniert, die Kollegen wollen es auch, und ein halbes Jahr später hängen fünf Leute, zwei Preislisten und ein Teil der Kundenkommunikation daran.
Irgendwann kommt der Moment, an dem jemand fragt: Was passiert eigentlich, wenn das Ding ausfällt? Spätestens dann steht die Frage im Raum, wie der Weg vom Prototyp zur Software aussieht, also von etwas, das läuft, zu etwas, auf das sich ein Betrieb verlassen kann. Ein Vibe-Coding-Prototyp ist dafür kein schlechter Start, im Gegenteil. Aber er ist ein Start und kein Ziel.
Dieser Beitrag klärt, woran du merkst, dass dein Prototyp erwachsen werden muss, welche zwei Wege es gibt und wie du zwischen ihnen entscheidest, was ein Entwickler dabei konkret macht und wie du den Prototyp so übergibst, dass möglichst wenig verloren geht.
Sieben Zeichen, dass dein Prototyp erwachsen werden muss
Andrej Karpathy, der den Begriff Vibe Coding im Februar 2025 geprägt hat, hielt die Methode selbst für Wegwerfprojekte am Wochenende geeignet. Das ist keine Abwertung, sondern eine ehrliche Einordnung: Vibe Coding ist ideal, um schnell etwas auszuprobieren. Was genau dahintersteckt, steht in Was ist Vibe Coding? Problematisch wird es, wenn aus dem Wochenendprojekt still und leise ein Betriebsmittel wird. Diese sieben Zeichen zeigen, dass es so weit ist:
- Andere verlassen sich darauf. Solange nur du das Tool nutzt, ist ein Ausfall ärgerlich. Wenn das Team morgens nicht arbeiten kann, weil die App hängt, ist es ein Betriebsrisiko.
- Echte Kundendaten sind drin. Adressen, Konditionen, Aufträge, Dokumente. Ab hier zählt nicht mehr nur, ob die App funktioniert, sondern auch, wer was sehen kann und ob die Daten nach einem Fehler wieder da sind.
- Sie soll an bestehende Systeme andocken. Sobald das Tool Daten aus dem ERP holen, ins CRM schreiben oder die Buchhaltung beliefern soll, wird es Teil deiner Systemlandschaft. Schnittstellen, die nur meistens funktionieren, erzeugen doppelte Pflege statt weniger.
- Fehler kommen wieder. Die KI repariert einen Fehler, dafür taucht ein alter wieder auf. Wenn sich dieses Muster wiederholt, fehlt meist eine saubere Struktur, und weiteres Nachbessern per Chat macht es selten besser.
- Niemand versteht den Code. Auch nicht die Person, die ihn hat schreiben lassen. Das ist beim Vibe Coding normal und kein Vorwurf, aber es bedeutet: Niemand kann sagen, was eine Änderung sonst noch auslöst.
- Die Kosten steigen. Höhere Tarife bei der Plattform, mehr Nutzerlizenzen, wachsende Rechnungen bei der KI-Schnittstelle, und dazu die Stunden, die Leute mit Umwegen verbringen. Irgendwann ist das Provisorium teurer als eine saubere Lösung.
- Du stößt an Grenzen der Plattform. Eine Funktion lässt sich nicht bauen, eine Anbindung wird nicht unterstützt, oder der Tarif setzt Grenzen. Bei Supabase etwa können Projekte im kostenlosen Plan nach sieben Tagen ohne Aktivität pausiert werden, und automatische Sicherungen gibt es dort nicht. Wie sich die gängigen Werkzeuge hier unterscheiden, steht in Vibe-Coding-Tools im Vergleich.
Ein Zeichen allein ist noch kein Grund zum Handeln. Treffen zwei oder mehr zu, besonders die ersten beiden, lohnt es sich, bewusst zu entscheiden, statt weiter nachzubessern.
Die zwei Wege: härten oder sauber neu bauen
Wenn der Prototyp erwachsen werden soll, gibt es im Kern zwei Wege. Beide sind legitim, und welcher besser ist, hängt weniger vom Werkzeug ab, mit dem der Prototyp gebaut wurde, als von seinem Zustand.
Härten heißt: Der vorhandene Code bleibt die Grundlage. Er wird aufgeräumt, abgesichert, mit Tests versehen und in eine eigene Umgebung umgezogen. Das lohnt sich, wenn die Struktur im Kern trägt und nur die unsichtbaren Teile fehlen, also Sicherheit, Sicherungen, Überwachung und Betreuung. Welche das sind, steht in der Prüfliste vor dem Livegang.
Sauber neu bauen heißt: Der Prototyp wird zur Vorlage, der Code nicht. Die Anwendung entsteht mit einer durchdachten Architektur und einem tragfähigen Datenmodell neu, und die bestehenden Daten werden übernommen. Das klingt nach mehr Aufwand, ist aber oft der schnellere Weg, wenn der Prototyp an seinen Grundmauern hakt.
Diese Kriterien helfen bei der Entscheidung:
| Kriterium | Eher härten | Eher neu bauen |
|---|---|---|
| Datenmodell | Passt im Kern, Tabellen und Beziehungen ergeben Sinn | Grundlegend schief, etwa kein Konzept für Nutzer, Rollen oder mehrere Standorte |
| Code-Struktur | Nachvollziehbar, verbreiteter Technik-Stack | Flickenteppich aus vielen Reparaturen, niemand traut sich an Änderungen |
| Anforderungen | Der Prototyp deckt das Wesentliche schon ab | Das eigentliche Ziel hat sich seit dem Prototyp deutlich verschoben |
| Anbindungen | Wenige, einfache Schnittstellen | Mehrere Systeme wie ERP, CRM und Buchhaltung, die sauber zusammenspielen müssen |
| Plattform | Code lässt sich exportieren und läuft auch außerhalb | Wesentliche Teile hängen an Funktionen, die es nur auf der Plattform gibt |
| Nutzung | Überschaubarer Kreis, wenig gleichzeitige Nutzung | Kunden oder viele Nutzer, hohe Anforderungen an Stabilität |
Häufig liegt die Antwort dazwischen. Die Oberfläche und die Abläufe bleiben erhalten, weil sie sich im Alltag bewährt haben, während Datenmodell und Logik dahinter neu entstehen. Genau deshalb steht vor jeder Entscheidung eine ehrliche Prüfung des Bestands, und nicht das Bauchgefühl.
Was ein Entwickler konkret macht
„Das muss mal ein Profi anschauen" klingt nach Blackbox. Ist es nicht. So sieht die Arbeit in der Regel aus, und so würde ich sie auch angehen:
- Prüfung des Bestands. Code, Datenbank, Zugänge und verwendete Pakete werden durchgesehen. Wo liegen Sicherheitslücken, was ist tragfähig, was ist Flickwerk? Am Ende steht eine klare Empfehlung: härten oder neu bauen.
- Anforderungen klären. Was muss die Software können, und was bewusst nicht? Der Prototyp beantwortet viele dieser Fragen schon, aber nicht alle, etwa Rollen, Sonderfälle und was passiert, wenn etwas schiefgeht. Warum diese Beschreibung vor dem Bauen so viel ausmacht, steht in Spec-Driven Development.
- Architektur und Datenmodell. Wer darf was sehen, wie hängen Kunden, Aufträge und Dokumente zusammen, welche Systeme liefern Daten und welche bekommen welche? Das ist der Teil, den man einer fertigen App später am wenigsten ansieht und am meisten spürt.
- Tests. Die wichtigsten Abläufe, etwa ein Angebot berechnen oder einen Auftrag anlegen, bekommen automatische Tests. Dann fällt bei jeder Änderung sofort auf, wenn etwas anderes kaputtgeht, statt erst beim Kunden.
- Umzug auf eigenen Stack und eigenes Hosting. Der Code liegt in einem Repository, das dir gehört, und läuft in einer Umgebung, die du auswählst. Ich setze dafür auf einen verbreiteten Stack aus React, Next.js und TypeScript mit einer passenden Datenbank, bewusst ohne Nischen-Framework, damit die Software nicht an einer einzelnen Person hängt. Warum Versionskontrolle dabei die Grundlage ist, steht in Git erklärt.
- Betrieb. Überwachung, Sicherungen, Updates und Sicherheit laufen geregelt, und jemand ist zuständig. Das kann ich übernehmen, du kannst die Software aber auch selbst betreiben, wenn der Code sauber dokumentiert übergeben ist.
Das alles passiert nicht in einem großen Wurf am Ende, sondern in kleinen, testbaren Etappen mit regelmäßig nutzbaren Ständen. Du siehst früh, wohin es geht, und kannst korrigieren, bevor viel Aufwand in die falsche Richtung fließt. KI-Werkzeuge nutze ich dabei selbst täglich, nur eben mit Tests, Prüfung und einem Plan dahinter. Worin sich das vom Vibe Coding unterscheidet, steht in Vibe Coding oder KI-gestützte Softwareentwicklung.
Warum der Prototyp trotzdem Gold wert ist
Wer hört, dass sein Prototyp womöglich neu gebaut wird, fühlt sich oft, als hätte er Zeit verschwendet. Das Gegenteil ist der Fall.
Ein funktionierender Prototyp ist die beste Anforderungsbeschreibung, die du liefern kannst. Er zeigt, welche Masken es braucht, welche Felder wirklich ausgefüllt werden und in welcher Reihenfolge die Leute klicken. Ein Lastenheft beschreibt, wie Arbeit laufen soll. Ein Prototyp, den das Team seit Monaten nutzt, zeigt, wie sie tatsächlich läuft.
In meinem Vorgehen ist der zweite Schritt ohnehin ein klickbarer Prototyp, weil man an etwas Greifbarem früher merkt, was fehlt, als an einem Dokument. Wenn du mit einem Vibe-Coding-Prototyp kommst, hast du diesen Schritt zu einem guten Teil schon selbst erledigt, und zwar mit echten Nutzern. Außerdem hast du bewiesen, dass der Bedarf echt ist. Die Frage, ob jemand die Software überhaupt nutzen würde, ist damit beantwortet.
Und der Prototyp zeigt, was du nicht brauchst. Funktionen, die du eingebaut hast und die niemand nutzt, kommen in die echte Software gar nicht erst hinein. Das spart mehr, als man denkt. Wie du die restlichen Anforderungen sauber aufschreibst, steht in Anforderungen für ein KI-Projekt aufschreiben.
So übergibst du den Prototyp
Je besser die Übergabe, desto schneller die Einschätzung und desto weniger geht verloren. Diese fünf Dinge solltest du vorbereiten:
- Zugänge. Plattform, Code-Repository, Datenbank, Domain, KI-Anbieter, Mailversand. Am besten lädst du den Entwickler als zusätzlichen Nutzer ein, statt Passwörter zu verschicken. So kannst du den Zugang später auch wieder entziehen.
- Code-Export. Der Code sollte in einem Git-Repository liegen, das dir gehört. Lovable etwa kann Projekte mit GitHub synchronisieren. Denk daran, dass Code und Daten getrennt sind: Die Datenbank exportierst du separat, bei Supabase zum Beispiel über das Kommandozeilenwerkzeug.
- Die Liste der Macken. Was funktioniert nicht, welche Umwege nutzt das Team, welchen Knopf fasst man besser nicht an? Diese Liste ist Gold wert, weil sie zeigt, wo der Prototyp schon heute an seine Grenzen kommt.
- Beispiele echter Nutzung. Drei bis fünf typische Fälle, am besten als kurze Bildschirmaufnahme: So legen wir ein Angebot an, so ändern wir einen Auftrag. Dazu die Info, wer das Tool wie oft wofür nutzt.
- Was bleiben muss und was weg kann. Welche Teile haben sich bewährt, welche waren Experimente? Wenn du den Verlauf mit der KI noch hast, hilft er ebenfalls, weil er zeigt, welche Entscheidungen warum gefallen sind.
Ein praktischer Hinweis: Während der Übergabe solltest du keine größeren Umbauten mehr per KI vornehmen. Sonst wird die Einschätzung zur Momentaufnahme eines Ziels, das sich täglich verschiebt.
Wie lange es dauert und wovon die Kosten abhängen
Ein erster nutzbarer Stand steht in meinen Projekten oft in 4 bis 8 Wochen. Kleinere interne Tools gehen schneller, umfangreiche Anwendungen mit vielen Anbindungen dauern länger. Weil in Etappen geliefert wird, wartest du nicht monatelang auf ein Ergebnis, und der Prototyp kann bis zur Umstellung weiterlaufen.
Einen Katalogpreis gibt es nicht, weil die Spanne zu groß ist. Die Kosten treiben vor allem vier Dinge: die Zahl der Anbindungen an andere Systeme, die Komplexität von Rollen und Berechtigungen in der App, der Aufwand für die Übernahme der bestehenden Daten und die Ansprüche an den Betrieb. Wie sich solche Projekte grundsätzlich zusammensetzen, steht in Was kostet ein KI-Projekt im Mittelstand?
Und manchmal lautet die ehrliche Antwort: Du brauchst gar keine eigene Software. Wenn der Prototyp zeigt, dass ein Standardwerkzeug neunzig Prozent abdeckt, ist das oft die bessere Wahl. Wann sich Eigenbau lohnt, steht in Eigene Software entwickeln, und wie du die Rechnung aufmachst, in Selbst bauen oder kaufen?
Häufige Fragen
Kann ein Entwickler meinen Lovable-Prototyp weiterentwickeln?
Ja, wenn der Code exportierbar ist. Lovable kann Projekte mit GitHub synchronisieren, und von dort kann ein Entwickler lokal weiterarbeiten. Ob er den Code weiterführt oder als Vorlage für einen Neubau nutzt, hängt vom Zustand ab, nicht vom Werkzeug.
Muss ich meinen Vibe-Coding-Prototyp komplett neu programmieren lassen?
Nicht zwingend. Trägt das Datenmodell und ist der Code nachvollziehbar, reicht oft Härten: absichern, testen, umziehen. Ein Neubau lohnt sich vor allem dann, wenn das Fundament schief ist oder sich die Anforderungen stark verschoben haben. Häufig bleibt die Oberfläche erhalten und die Logik dahinter wird neu gebaut.
Wie lange dauert der Weg vom Prototyp zur fertigen Software?
Ein erster nutzbarer Stand steht oft in 4 bis 8 Wochen. Kleinere interne Tools gehen schneller, Anwendungen mit vielen Anbindungen dauern länger. Weil in Etappen geliefert wird, bekommst du früh nutzbare Zwischenstände.
Kann ich danach selbst weiter mit KI daran bauen?
Ja, und das ist oft sinnvoll. Mit einem eigenen Repository, automatischen Tests und klaren Regeln, was geprüft wird, bevor etwas live geht, kannst du Werkzeuge wie Claude Code weiter nutzen. Der Unterschied zu vorher ist, dass die Tests Fehler auffangen, bevor sie deine Nutzer treffen.
Fazit
Ein Vibe-Coding-Prototyp ist kein Fehler, den ein Entwickler ausbügeln muss. Er ist der schnellste Weg herauszufinden, was du wirklich brauchst. Kritisch wird er erst, wenn er unbemerkt vom Experiment zum Betriebsmittel wird, mit echten Daten, echten Nutzern und niemandem, der zuständig ist.
Dann gibt es zwei ehrliche Wege: härten, wenn das Fundament trägt, oder sauber neu bauen, wenn es das nicht tut. Beide beginnen mit einer nüchternen Prüfung des Bestands und profitieren davon, dass der Prototyp schon zeigt, wie gearbeitet wird.
Wenn du wissen willst, wie das bei deinem Prototyp aussieht, schau dir an, wie ich Softwareentwicklung angehe, oder buch direkt eine kostenlose Prozessanalyse. Bist du noch nicht so weit und suchst erst den größten Hebel für KI in deinem Betrieb, hilft der KI-Potenzial-Check.