Kurz gesagt: Mit Lovable, Bolt, Replit oder Cursor entsteht in kurzer Zeit ein Prototyp, der sich wie eine echte App anfühlt. Bis zu einem Produkt, dem Nutzer ihre Daten und ihr Geld anvertrauen, fehlt meist noch ein Stück: Sicherheit, ein belastbares Datenmodell, Anmeldung mit Rechten, echte Zahlungen, Tests und ein Betrieb auf Ihren eigenen Konten. Dieser Artikel zeigt, was KI-Builder gut können, wo die typischen Lücken liegen und wie wir weiterarbeiten: zuerst ein Audit, dann ein Angebot.
Was KI-Builder gut können
Lovable, Bolt und Replit bauen aus einer Beschreibung eine lauffähige Web-App, oft schon mit Datenbank und Anmeldung. Cursor ist ein Code-Editor mit KI für Menschen, die selbst programmieren. Für diese Arbeitsweise hat sich der Begriff „Vibe Coding“ eingebürgert: Sie beschreiben, die KI baut. Das hat echten Wert:
- Die Idee wird sichtbar. Ein klickbarer Prototyp erklärt Ihr Vorhaben oft besser als ein Lastenheft.
- Feedback kommt früh. Sie können Nutzern, Partnern oder Geldgebern etwas zeigen, bevor viel Budget fließt.
- Der Einstieg kostet wenig. Der Pro-Tarif von Lovable beginnt laut einer Preisübersicht vom Juni 2026 bei 25 US-Dollar pro Monat. Das Hosting über Lovable Cloud wird zusätzlich nach Nutzung abgerechnet [1].
Ein Prototyp ist für uns deshalb ein guter Ausgangspunkt. Er zeigt genau, was Sie wollen. Offen ist nur, was bis zum Livegang noch fehlt.
Typische Lücken zwischen Prototyp und Produkt
Ein Prototyp soll zeigen, dass eine Idee funktioniert. Ein Produkt muss auch dann funktionieren, wenn jemand es falsch bedient, angreift oder in zwei Jahren erweitert. Diese Lücken sind bei KI-gebauten Apps typisch:
| Bereich | Typische Lücke im Prototyp | Was vor dem Livegang nötig ist |
|---|---|---|
| Sicherheit | Geheime Schlüssel im Code, den der Browser lädt; fehlende Zugriffsregeln in der Datenbank; ungeprüfte Eingaben | Sicherheitsprüfung, Zugriffsregeln je Tabelle, Schlüssel nur auf dem Server |
| Datenmodell | Tabellen wachsen Prompt für Prompt, Daten liegen doppelt, Änderungen laufen ohne Migrationen | Ein bereinigtes Modell mit Migrationen und Backups |
| Anmeldung und Rechte | Der Login funktioniert, aber Rollen, Passwort-Reset und Kontolöschung fehlen | Rollen und Rechte je Funktion, vollständige Abläufe rund um das Konto |
| Zahlungen | Läuft nur im Testmodus, ohne Rückmeldungen des Zahlungsanbieters (Webhooks) und ohne Belege | Live-Konto, Webhooks, Belege, ein Plan für abgelehnte Zahlungen |
| Tests | Keine automatisierten Tests; jede Änderung kann Bestehendes brechen | Tests für die Kernabläufe |
| Wartbarkeit | Doppelter Code, sehr lange Dateien, keine erkennbare Struktur | Aufräumen, klare Struktur, kurze Dokumentation |
| Hosting und Kosten | Betrieb auf dem Konto des Werkzeugs, nutzungsabhängige Kosten, unklarer Speicherort der Daten | Konten auf Ihren Namen, bekannte laufende Kosten, geklärter Datenstandort |
Zwei Auswertungen zeigen, warum ein zweiter Blick nötig ist:
- Sicherheit: Veracode ließ über 100 KI-Modelle Code schreiben. 45 % der Codebeispiele fielen durch Sicherheitstests und enthielten Schwachstellen aus den OWASP Top 10, einer Liste verbreiteter Risiken in Web-Anwendungen (Juli 2025) [2].
- Wartbarkeit: GitClear hat 211 Millionen Codezeilen ausgewertet. Von 2021 bis 2024 stieg der Anteil kopierter Zeilen von 8,3 % auf 12,3 %. Der Anteil geänderter Zeilen, die auf Umbauten (Refactoring) entfallen, sank von 25 % auf unter 10 % [3]. In derselben Zeit haben sich KI-Assistenten verbreitet. GitClear verkauft selbst Werkzeuge zur Code-Analyse; die Zahlen zeigen einen Trend, keinen Befund über Ihr Projekt.
Das heißt nicht, dass KI-Code schlecht ist. Es heißt: Jemand muss ihn lesen, prüfen und aufräumen, bevor echte Nutzer kommen. Wir arbeiten selbst KI-gestützt. Der Unterschied: Jede Zeile, die zu Ihnen geht, liest und testet Samuel Rogers.
Fertigstellen oder neu bauen?
Nicht jeder Prototyp sollte weitergebaut werden. Oberfläche, Abläufe und Texte lassen sich meist übernehmen; darin steckt Ihre Arbeit mit dem Werkzeug. Beim Code darunter kommt es auf Datenmodell und Anmeldung an. Manchmal ist es günstiger, die Logik neu und sauber zu bauen, als sie zu flicken. Das entscheidet das Audit, nicht ein Bauchgefühl. Ist ein Neubau günstiger, sagen wir es Ihnen, bevor Sie etwas beauftragen.
So machen wir aus dem Prototyp ein Produkt
- Anfrage. Sie beschreiben im Anfrageformular, was die App können soll, und wählen unter „Vorhandenes“ die Option „Bestehender Code“. Ein Link zum Prototyp hilft.
- Audit. Bevor wir Code ändern, prüfen wir ihn. Was das Audit umfasst, steht im Kasten unten.
- Angebot. Ist der Umfang nach dem Audit klar abgrenzbar, erhalten Sie ein Festpreisangebot für die Fertigstellung, mit „Enthalten“ und „Nicht enthalten“. Fremdkosten stecken nie im Festpreis: Hosting, Tarife für Datenbank und KI-Dienste, Domain, Store-Gebühren und Lizenzen zahlen Sie direkt auf Ihren Konten. Wo der Code für einen Festpreis zu unklar ist, arbeiten wir nach Aufwand: 75–95 € pro Stunde netto (89,25–113,05 € pro Stunde inkl. 19 % USt.), vorab geschätzt und mit einer Aufstellung der Stunden je Aufgabe. Wann welches Modell passt und was es rechtlich bedeutet, erklärt der Artikel Festpreis oder Stundensatz?
- Fertigstellung. In der Reihenfolge, die das Audit festlegt, meist zuerst Sicherheit und Datenmodell, dann Anmeldung, Zahlungen und Tests. Nach jedem Abschnitt bekommen Sie eine Testversion.
- Übergabe. Mit vollständiger Zahlung gehören Ihnen Quellcode, Zugänge und die Nutzungsrechte an unserer Arbeit.
Bestandscode-Audit (Legacy): ab 900 € netto (1.071 € inkl. 19 % USt.)
- Repository- und Architektur-Prüfung
- Risikoliste und Migrationsplan
- Aufwandsschätzung für die nächsten Schritte
Lieferzeit: 1 Woche nach Zugang zum Repository. Einen Festpreis für die Arbeit an bestehendem Code nennen wir erst nach dem Audit. Das Paket in der Preisliste
Was Sie für das Audit bereitstellen
- Zugang zum Code-Repository, zum Beispiel über die GitHub-Anbindung Ihres Werkzeugs; für das Audit genügt Lesezugriff
- Lesezugriff auf Hosting und Datenbank, etwa bei Supabase, Vercel, Netlify oder Cloudflare
- Eine Liste der angebundenen Dienste: Zahlungen, E-Mail-Versand, KI-Schnittstellen, Statistik
- Den Link zum laufenden Prototyp und ein Testkonto je Rolle
- Was schon funktioniert, was nicht und was zum Start fertig sein muss
- Ob bereits echte Nutzerdaten gespeichert sind; dann gelten die Datenschutzpflichten schon heute
Zugangsdaten schicken Sie bitte nicht per E-Mail. Wir vereinbaren vorher einen sicheren Weg, und nach dem Projekt entziehen Sie die Zugänge wieder. Konten, Domain und spätere Store-Einträge sollten auf Ihren Namen laufen. Ihr Code wird nicht zum Training fremder KI-Modelle freigegeben.
Checkliste: Ist Ihr Prototyp bereit für echte Nutzer?
- Sieht jeder Nutzer nur seine eigenen Daten, auch wenn er Anfragen im Browser verändert?
- Liegen geheime Schlüssel nur auf dem Server?
- Gibt es Backups, und wurde eine Wiederherstellung schon einmal getestet?
- Laufen Zahlungen im Live-Modus, und was passiert bei einer abgelehnten Karte?
- Gibt es automatische Tests für die Kernabläufe?
- Wissen Sie, was der Betrieb bei zehnmal so vielen Nutzern kostet?
- Laufen alle Konten auf Ihren Namen?
- Passen Impressum und Datenschutzerklärung zu den Diensten, die die App tatsächlich nutzt?
Beantworten Sie eine dieser Fragen mit Nein oder „Weiß nicht“, lohnt sich ein Audit vor dem Livegang.
Nächster Schritt
Sie haben einen Prototyp und wollen wissen, was bis zum Livegang fehlt? Prototyp prüfen lassen: Im Anfrageformular ist die Projektart App dann schon gewählt; unter „Vorhandenes“ kreuzen Sie „Bestehender Code“ an. Für neue Apps ohne bestehenden Code lesen Sie weiter unter App entwickeln lassen; eine erste Spanne zeigt der Kostenrechner. Wie wir selbst mit KI arbeiten, steht unter Was KI bei uns macht.