Ihr Lovable-Prototyp funktioniert. Das braucht er vor echten Nutzern.

Tools wie Lovable, Bolt und Cursor haben verändert, wie Produkte beginnen. Gründer haben am Dienstagnachmittag eine klickbare App, zeigen sie bis Freitag zehn potenziellen Kunden und lernen dabei mehr als in einem Monat mit Folien.

Dann ändert sich die Frage. Menschen wollen sich registrieren, bezahlen und wiederkommen. In diesem Moment muss aus einem Prototyp ein Produkt werden, und genau dort steckt die meiste unsichtbare Arbeit.

Wir bauen selbst jeden Tag mit KI. Das hier ist also kein Argument gegen diese Tools, sondern eine Checkliste für das, was zwischen "funktioniert auf meinem Bildschirm" und "Kunden verlassen sich darauf" meistens Aufmerksamkeit braucht.

1. Wer welche Daten sehen kann

Die wichtigste Frage wird am leichtesten übersprungen. Legen Sie zwei Testkonten an und versuchen Sie, mit dem zweiten Konto die Daten des ersten zu öffnen. Wenn das klappt, ist die App nicht bereit für echte Nutzer, egal wie gut sie aussieht.

Generierter Code prüft Berechtigungen oft in der Oberfläche und vergisst die Datenbank oder die API dahinter. Die Lösung ist selten groß, sie muss aber bewusst gebaut werden: Regeln für jede Tabelle und jeden Endpunkt, getestet mit mehr als einem Nutzer.

2. Schlüssel und Zugangsdaten

Prototypen sammeln schnell API-Schlüssel: für Zahlungen, E-Mail, Karten und KI-Modelle. Prüfen Sie, dass keiner davon im Code steckt, der im Browser läuft, und dass keiner jemals ins Repository eingecheckt wurde. Ein Schlüssel, der vor drei Commits gelöscht wurde, steht immer noch in der Historie. Tauschen Sie alles aus, was offen lag.

3. Ein Datenmodell, das wachsen kann

Die Datenbank eines Prototyps ist von der ersten Demo geprägt. Bevor echte Daten hineinkommen, lohnt ein frischer Blick. Sind Nutzer, Konten und Rollen getrennte Konzepte? Kann ein Kunde ein zweites Teammitglied hinzufügen? Lässt sich ein Nutzer sauber löschen, wenn er darum bittet? Das später mit Live-Daten zu ändern, ist deutlich teurer als jetzt.

4. Login, Zahlungen und E-Mails

Das sind die Teile, die Kunden bemerken, wenn sie nicht funktionieren. Passwort zurücksetzen, E-Mail-Bestätigung, fehlgeschlagene Zahlungen, Erstattungen, gekündigte Abos und Rechnungen müssen funktionieren, nicht nur der Idealfall. Nutzen Sie dafür, wo immer möglich, die Bausteine der Anbieter, statt sie nachzubauen.

5. Merken, wenn etwas kaputtgeht

Im Prototyp finden Sie Fehler, weil Sie selbst durchklicken. Mit echten Nutzern brauchen Sie Fehler-Logging und Benachrichtigungen, damit Sie von einem Problem erfahren, bevor ein Kunde Ihnen schreibt. Dazu kommen Backups, und ein Test, ob Sie eines wirklich wiederherstellen können.

6. Updates als Routine

Jede App hängt von Dutzenden Paketen ab, und jedes davon bekommt Sicherheitsupdates. Werden Abhängigkeiten über Versionskontrolle aktualisiert, getestet und ausgerollt, geht ein Fix in Minuten live. Hängen Updates davon ab, dass jemand daran denkt, passieren sie nicht. Die aktuelle PHP2Shell-Lücke zeigt, wie schnell das wichtig wird.

7. Eine Oberfläche, der Menschen vertrauen

Generierte Oberflächen sehen sich oft ähnlich: dasselbe Layout, dieselben Karten, dieselben Formulierungen. Für einen Test ist das in Ordnung. Für ein Produkt, das Menschen nach ihren Daten oder ihrem Geld fragt, kostet es Vertrauen. Die häufigsten Merkmale haben wir in Anzeichen eines KI-gemachten Produkts beschrieben.

Behalten, neu bauen oder neu anfangen?

Die meisten Prototypen müssen nicht weggeworfen werden. Eine Prüfung von Code, Datenmodell, Sicherheit und den wichtigsten User Flows zeigt meist: Manches kann bleiben, manches muss neu gebaut werden, und einiges fehlt noch. Erst dieses Bild macht die Entscheidung und das Budget konkret.

• Behalten, was abgegrenzt, lesbar und durch die Punkte oben abgedeckt ist.
• Neu bauen, was Berechtigungen, Zahlungen oder das Datenmodell betrifft und für die Demo improvisiert wurde.
• Neu anfangen nur dann, wenn der Prototyp in so viele Richtungen gewachsen ist, dass Ändern mehr kostet als ein Neubau auf Basis dessen, was Sie gelernt haben.

Der Prototyp hat seine Aufgabe erfüllt, wenn er gezeigt hat, was gebaut werden soll. Das Produkt ist das, was Sie als Nächstes bauen.

Wenn Sie einen Prototyp haben, den Menschen nutzen wollen: Auf unserer Seite für Gründer erklären wir, wie wir ihn prüfen, produktreif machen und mit Ihnen launchen.