Vibe Coding für Nicht-Entwickler: Was Sie 2026 gefahrlos bauen können

Nicht-Entwickler können 2026 erstaunlich viel per Vibe Coding bauen, bis zu einer Grenze, die sich klar benennen lässt. Darunter liegen Prototypen, Landingpages, interne Tools und einfache Apps mit Login und Datenbank. Darüber liegen individuelle Zahlungslogik, Gesundheits- oder Finanzdaten, Apps, die viele Unternehmen gemeinsam nutzen, und alles mit ernstem Traffic. Dafür braucht es weiterhin einen Entwickler.

Die Zielgruppe ist längst da. Lovable gibt an, dass 80 % seiner Nutzer sich als nicht technisch bezeichnen und das Tool neben Websites auch für interne Tools, CRMs und Onlineshops einsetzen (The Next Web). Die Pannen kamen mit. In diesem Jahr fand UpGuard 16.326 Datenbanken auf Supabase, dem Backend, auf dem viele dieser Apps laufen, deren Tabellen jeder im Internet lesen konnte (UpGuard). Veracode hat über vier Jahre mehr als 100 KI-Modelle getestet und beziffert die durchschnittliche Security-Bestehensquote von KI-generiertem Code auf 56 %. Mit den Worten des Unternehmens: „It hasn't moved" (Veracode).

Der Großteil des Schadens geht auf einen einzigen Fehler zurück, den Sie ohne Code-Kenntnisse prüfen können: eine Datenbank, die Zeilen an jeden herausgibt, der danach fragt. Beheben Sie das, halten Sie geheime Schlüssel aus dem Browser heraus, und das meiste, was Gründerinnen, Marketer oder Analysten bauen wollen, ist unbedenklich.

So sieht Vibe Coding 2026 aus

Sie beschreiben in normaler Sprache, was Sie wollen, das Tool schreibt den Code, Sie klicken sich durch eine Live-Vorschau und bitten um die nächste Änderung. Die Tools für Nicht-Entwickler gehen heute weit über die Oberfläche hinaus. Sie legen auch Datenbank, Registrierung und Hosting an, sodass nach einem Nachmittag Prompting eine App mit echten Konten stehen kann.

Lesen Sie das Diagramm als Schleife mit einem Ausgang. Den Ausgang überspringen die meisten.

Der gestrichelte Pfeil geht bewusst vom Testen ab. Generierten Code können Sie nicht beurteilen, indem Sie ihn lesen, aber Sie können beurteilen, was er tut: ob ein zweites Konto die Datensätze des ersten sieht oder ob sich eine Seite ohne Login öffnen lässt. Sobald ein Test Geld, fremde private Daten oder echte Skalierung berührt, hören Sie auf und holen jemanden dazu, der Code lesen kann.

Dieses Jahr hat sich viel getan. Lovable lässt eine einzelne Build-Nachricht jetzt bis zu 10 Stunden laufen und hat einen /goal-Befehl ergänzt, der weitermacht, bis eine Aufgabe erledigt ist – zu einem deutlich höheren Preis (Lovable changelog). Replit hat Agent 4 mit parallelen Agents veröffentlicht, und die KI läuft dort jetzt im Free Mode sowie in den kostenpflichtigen Modi Power und Max. Vercel hat v0 rund um GitHub-Branches und Pull Requests neu aufgebaut; laut dem Produktchef besteht 90 % der echten Arbeit darin, eine bestehende Codebasis zu ändern. Base44 von Wix hat ein eigenes Modell namens Base1 trainiert, das nach Erwartung des Gründers für Kunden irgendwann schneller und günstiger sein soll als Frontier-Modelle.

Google AI Studio erkennt inzwischen, wenn eine App eine Datenbank oder einen Login braucht, und richtet nach Ihrer Freigabe dafür Firebase ein. Der ältere Builder Firebase Studio wird eingestellt, jedes darauf aufbauende Tutorial ist also bereits veraltet.

Die Risikoleiter: Was Sie allein bauen können

Das Risiko steigt mit zwei Faktoren: wessen Daten die App hält und ob Geld durch sie fließt. Ein Prototyp voller erfundener Datensätze kann nichts preisgeben. Eine Anmelde-App mit den E-Mail-Adressen fremder Personen kann es, und in diesem Jahr haben das etliche getan.

Die Leiter ordnet gängige Projekte nach diesem Risiko. Die unteren drei Sprossen sind für jeden machbar. Die orangefarbene ist die, auf der die meisten Datenlecks dieses Jahres passiert sind.

Klickbare Prototypen, Landingpages mit Kontaktformular und rein teaminterne Tools sind der ideale Einstieg. Ein Prototyp beantwortet die Frage „Sollen wir das bauen?", bevor jemand ein Ticket schreibt. Ein internes Tracking-Tool für ein Vertriebs- oder Ops-Team kann eine Tabelle ersetzen, der niemand traut, und wenn es auf den Workspace beschränkt und per Login geschützt ist, könnten nur Ihre Kollegen es missbrauchen. Auch einfache Automatisierungen gehören auf diese Sprosse, wobei ein Workflow-Tool wie n8n oder Zapier die Aufgabe oft ganz ohne eigene App erledigt (siehe das Ranking für Workflow-Automatisierung).

Kunden-Apps mit Konten sind die orangefarbene Sprosse. Die Tools können sie problemlos bauen. Das Problem: Eine falsche Datenbankregel legt alle Nutzer auf einmal offen. Bauen Sie die App also und lassen Sie sie von einem Entwickler prüfen, bevor sich echte Menschen registrieren.

Die obersten zwei Sprossen gehören Entwicklern. Zuerst die Zahlungen. Ein Kaufen-Button, der den gehosteten Stripe-Checkout öffnet, ist unproblematisch, weil die Kartendaten direkt an Stripe gehen und nie durch Ihre App laufen. Stripes eigener Sicherheitsleitfaden warnt, dass ein Unternehmen, das Kartendaten direkt verarbeitet, unter PCI DSS womöglich mehr als 300 Sicherheitskontrollen erfüllen muss. Nutzungsbasierte Abrechnung und Apps, in denen mehrere Unternehmen sich eine Datenbank teilen, hängen beide von Autorisierungslogik ab, und genau dort finden Forscher immer wieder kaputte KI-Apps.

Der zweite Punkt sind regulierte Daten. Laut der Enterprise-FAQ von Lovable unterzeichnet das Unternehmen keine Business Associate Agreements, ist nicht HIPAA-konform und bittet Nutzer, keine geschützten Gesundheitsdaten hochzuladen. Gesundheits-, Finanz- und Kinderdaten bringen rechtliche Pflichten mit sich, die kein Scan vor der Veröffentlichung abdecken kann.

Die wichtigsten Tools heute und wie sie abrechnen

Fünf Builder decken das meiste ab, was diese Zielgruppe braucht, und sie unterscheiden sich weniger in dem, was sie bauen können, als darin, wie sie abrechnen und wie leicht Sie wieder wegkommen. Bolt und v0 stehen neben Lovable, Replit und Base44. Die Preise sind die Einstiegstarife laut der jeweiligen Preisseite.

Für die meisten Nicht-Entwickler ist Lovable die vernünftige Standardwahl. Es veröffentlicht Beispielkosten pro Nachricht, scannt bei jeder Veröffentlichung auf Sicherheitsprobleme, und der Code lässt sich in jedem Tarif, auch im kostenlosen, mit GitHub synchronisieren. Base44 passt zu Leuten, die nie Code sehen wollen, mit einem Haken, der im Abschnitt zur Übergabe unten behandelt wird. Replit ist sinnvoll, wenn Sie einen Workspace für Apps, Folien und Daten-Dashboards wollen, und der Free Mode ist der sanfteste Einstieg. Bolt passt zu Leuten, die in Schüben bauen, da ungenutzte bezahlte Tokens einen Monat lang übertragen werden. v0 ist die richtige Wahl, wenn Ihr Unternehmen ohnehin auf Vercel deployt und Entwickler das Projekt später übernehmen.

Zwei ältere No-Code-Optionen decken mit visuellen Editoren Ähnliches ab: Bubble baut Web- und Mobile-Apps, und Glide macht aus Tabellen Apps. Das Live-Ranking unten zeigt, wie die gesamte Kategorie aktuell abschneidet, und unser Überblick über KI-App-Builder geht auf ein Dutzend davon genauer ein.

Das Ranking umfasst auch Builder für Entwickler. Nutzen Sie es also zur Orientierung und die Tabelle für die Budgetplanung.

Warum Credits schneller verbrennen als geplant

Alle diese Tools rechnen mittlerweile die Arbeit der KI ab, nicht die Nachricht, die Sie senden. Das ist bei kleinen Änderungen fair und bei vagen teuer.

Lovable veröffentlicht die klarsten Beispiele. „Make the button gray" kostete 0,50 Credits, „Add authentication" 1,20 und „Build a landing page with images" 2,00, während eine Nachricht im Plan-Modus 1 Credit kostet (Lovable). Da eine einzelne Build-Nachricht jetzt stundenlang laufen kann, hält Lovable an und fragt nach, sobald eine einzelne Nachricht 20 Credits überschreitet; diesen Standardwert können Sie erhöhen oder abschalten. Top-ups im Pro-Tarif kosten 15 $ pro 50 Credits, also 0,30 $ pro Credit gegenüber 0,25 $ im 100-Credit-Tarif.

Die anderen funktionieren genauso, nur unter anderen Namen. Laut Help Center von Bolt entsteht der größte Teil des Token-Verbrauchs durch das Lesen und Synchronisieren Ihrer Projektdateien, derselbe Prompt kostet also mehr, je größer die App wird. v0 zählt Chatverlauf und Quelldateien als Input-Tokens. Base44 sagt, es gebe keine feste Gebühr pro Nachricht, und beziffert typische Änderungen auf etwa 0,5 bis 4 Credits. Replits Free Mode kostet innerhalb eines Kontingents nichts, aber Power und Max zehren von den monatlichen Credits, und zusätzliche Credit-Pakete verfallen sechs Monate nach dem Kauf.

Lovables Preisleiter zeigt, was das für ein Budget bedeutet.

Mengenrabatt gibt es kaum. Jede Stufe bis 800 Credits kostet 0,25 $ pro Credit, und die 2.000-Credit-Stufe liegt immer noch bei 0,24 $. Wer doppelt so viel promptet, zahlt doppelt so viel; der entscheidende Hebel sind also verschwendete Nachrichten.

Die meiste Verschwendung entsteht in Fix-Schleifen: Die KI macht etwas kaputt, ihre Korrektur macht etwas anderes kaputt, und jede Runde wird abgerechnet. Erst zu planen hilft, denn eine Plan-Modus-Nachricht kostet bei Lovable pauschal einen Credit, und Bolt sagt, der Plan-Modus verbrauche weniger Tokens, weil er nichts verändert. Auch Buttons helfen: Bolt weist darauf hin, dass das Veröffentlichen oder Wiederherstellen einer Version per Button nichts kostet, während die KI darum zu bitten Tokens verbraucht. Wenn eine Session aus dem Ruder läuft, springen Sie zu einem Checkpoint zurück, statt sich herauszuprompten.

Tragen Sie Ihre eigenen Gewohnheiten in den Rechner unten ein. Er nutzt Lovables Beispielkosten, verstehen Sie das Ergebnis also als Budgetspanne und nicht als Angebot.

Mit den Standardwerten brauchen Sie etwa 162 Credits im Monat, was der 50-$-Tarif abdeckt. Setzen Sie die Nacharbeit auf 60 %, steigt selbst die günstigere Variante, der 25-$-Tarif plus Top-ups, auf 70 $. Setzen Sie außerdem ein Limit: Lovables automatisches Aufladen akzeptiert ein monatliches Ausgabenlimit statt „No limit", und bei Replit können Sie die Ausgaben über die enthaltenen Credits hinaus deckeln. Wenn Ihnen die Credit-Preise weiterhin schleierhaft sind, erklärt unser Beitrag zu Preismodellen bei KI-Tools Credits, Seats und Tokens.

Die Vorfälle zeigen auf einen einzigen Fehler

Legt man die Vorfallsberichte dieses Jahres nebeneinander, taucht immer derselbe Fehler auf. Es ist kein raffinierter Hack. Es ist eine Datenbank, die jedem antwortet, der fragt.

UpGuards Studie fand rund 300.000 Domains mit Anzeichen für Supabase und 16.326 Datenbanken mit lesbaren Tabellen, bei mehr als der Hälfte mit Hinweisen auf personenbezogene Daten (UpGuard). Die Erklärung ist konkret: Tabellen, die über die API angelegt werden – so sprechen Coding-Agents mit Supabase –, bekommen Row-Level-Security nicht standardmäßig aktiviert. Supabases Sicherheitschef sagte gegenüber TechCrunch, Projekte seien standardmäßig sicher und Sicherheit sei eine geteilte Verantwortung.

Moltbook, ein soziales Netzwerk für KI-Agents, dessen Gründer sagte, er habe „nicht eine einzige Zeile Code geschrieben", ging mit seinem Supabase-Schlüssel im Seitencode und ohne Row-Level-Security-Policies live. Forscher von Wiz kamen an 1,5 Millionen API-Tokens, 35.000 E-Mail-Adressen und Tausende private Nachrichten heran, bevor das Team wenige Stunden nach dem Hinweis nachbesserte (Wiz).

Eine bei Lovable gehostete App legte laut dem Forscher Taimur Khan 18.697 Nutzerdatensätze offen, Tausende davon Schülerkonten. Er fand die Zugriffsprüfung verkehrt herum geschrieben: „The guard blocks the people it should allow and allows the people it should block" (The Register). Lovable erklärte, man biete vor der Veröffentlichung einen kostenlosen Sicherheitsscan an, es liege an den Nutzern, danach zu handeln, die verwundbare Datenbank sei nicht von Lovable gehostet gewesen und das Projekt habe Code enthalten, den Lovable nicht generiert hatte.

Auch Plattformen patzen. Später im Jahr zeigte ein Forscher, dass ein kostenloses Lovable-Konto Quellcode, Datenbank-Zugangsdaten und KI-Chatverläufe aus den öffentlichen Projekten anderer ziehen konnte. Lovable bezeichnete das Verhalten zunächst als beabsichtigt und so gewollt. Dann räumte das Unternehmen ein, dass der Verweis auf unklare Dokumentation nicht genüge, sagte „We'll do better" und erklärte, man habe seine API gepatcht, sodass auf Chats öffentlicher Projekte nicht mehr zugegriffen werden kann (The Register). Die Sicherheitsfirma RedAccess zählte rund 380.000 öffentlich erreichbare Apps, gebaut mit Lovable, Base44, Replit und Netlify, etwa 5.000 davon mit offenliegenden sensiblen Daten. Replits CEO entgegnete, dass öffentliche Apps erreichbar sind, sei erwartetes Verhalten, und Privatsphäre sei eine Einstellung mit einem Klick.

Die Forschung sagt von der anderen Seite dasselbe. Veracodes langjähriger Test zeigt, wie wenig klügere Modelle geholfen haben.

Selbst das beste Modell in Veracodes Runde 2026 scheitert bei fast jeder dritten Sicherheitsaufgabe, und auf Coding spezialisierte Modelle schneiden nicht besser ab als Allzweckmodelle. Eine separate Studie des Startups Tenzai baute 15 Apps mit fünf Coding-Agents und fand 69 Schwachstellen. Die schlimmsten betrafen Autorisierung und Geschäftslogik, klassische Injection-Bugs tauchten gar nicht auf. Das deckt sich mit den Vorfällen. KI schreibt Code, der funktioniert, fragt aber nicht, wer ihn nutzen darf, solange Sie es nicht verlangen.

Row-Level-Security auf Deutsch erklärt

So gebaute Apps sprechen oft direkt aus dem Browser mit der Datenbank, über einen Schlüssel, der von Haus aus öffentlich ist. Dass ein Fremder mit diesem Schlüssel nicht alles lesen kann, verhindert Row-Level-Security: Regeln in der Datenbank, die Zeile für Zeile festlegen, wer was lesen oder ändern darf. Lovables integriertes Backend und Bolts Datenbank nutzen beide diese Postgres-Regeln, dasselbe Modell wie Supabase.

Die Dokumentation von Supabase ist deutlich. Eine Tabelle in einem offenen Schema ohne RLS „is readable and writable by any role with a grant on it" (Supabase). Sobald RLS aktiviert ist, sieht der öffentliche Schlüssel nichts, bis eine Policy es erlaubt. Eine Policy ist kurz. Diese hier, wie Ihr Builder sie für eine Orders-Tabelle schreiben sollte, erlaubt jedem angemeldeten Nutzer, nur seine eigenen Zeilen zu lesen:

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

Sie müssen sie nicht selbst schreiben. Sie müssen aber bestätigen, dass für jede Tabelle eine existiert. Der geheime Schlüssel oder „Service-Role"-Schlüssel umgeht diese Regeln komplett, deshalb darf er niemals im Browser-Code stehen. Und alles in Ihrem Frontend, auch eine Prüfung wie „Ist dieser Nutzer Admin?", kann von der Person, die die App nutzt, verändert werden. Deshalb sagt Lovables Dokumentation, dass Frontend-Code nie Sicherheitsentscheidungen treffen sollte.

Ein sicherer Build-Prozess, Schritt für Schritt

Diese Reihenfolge hält Fehler billig: bis zum letzten Schritt Testdaten, echte Menschen erst ganz am Ende.

1. 1Schreiben Sie vor dem ersten Prompt eine einseitige Spezifikation. Legen Sie fest, wer die App nutzt, listen Sie die fünf oder sechs Screens auf, beschreiben Sie, was jede Nutzergruppe sehen und ändern darf, und benennen Sie, was nicht dazugehört. Fügen Sie sie im Plan-Modus ein und bitten Sie das Tool, Lücken darin zu suchen.
2. 2Prototypen Sie mit Testdaten. Bauen Sie Screens und Abläufe mit erfundenen Datensätzen, halten Sie das Projekt privat und zeigen Sie es den Leuten, die es nutzen werden. Ändern Sie jetzt die Richtung, solange eine Änderung nur eine Nachricht kostet.
3. 3Beschreiben Sie das Datenmodell in einfachen Worten. Listen Sie jede Art von Datensatz (Kunden, Bestellungen, Notizen) und wem er gehört auf, und bitten Sie das Tool, die Tabellen anzulegen und Tabelle für Tabelle zu erklären, wer Zeilen lesen und ändern darf. Lautet eine Antwort „jeder", beheben Sie das, bevor Sie weitermachen.
4. 4Ergänzen Sie Registrierung und Berechtigungen im selben Schritt und lesen Sie die Regeln anschließend noch einmal durch. Base44 etwa akzeptiert Regeln als Sätze wie „Only the person who submitted an order should be able to see it."
5. 5Testen Sie mit zwei Konten und Testdaten. Registrieren Sie sich als Alice und als Bob. Versuchen Sie als Bob, Alices Datensätze zu öffnen, ändern Sie die Datensatznummer in der Adressleiste und nutzen Sie die App ausgeloggt. Alles, was Bob erreicht und nicht erreichen sollte, ist ein Fehler, egal wie der Code aussieht.
6. 6Führen Sie den Security-Durchlauf aus. Nutzen Sie den integrierten Scan, beheben Sie jeden kritischen Befund und arbeiten Sie dann die Checkliste im nächsten Abschnitt ab. Bolts vollständiges Audit kostet keine Tokens, wenn Sie es über das Publish-Menü starten. Hält die App personenbezogene Kundendaten, lassen Sie sie hier von einem Entwickler prüfen.
7. 7Starten Sie klein und mit Limits. Laden Sie zunächst eine Handvoll echter Nutzer ein, setzen Sie Ausgabenlimits, prüfen Sie, dass Backups und Rollback funktionieren, und löschen Sie die Testkonten.

Sie sind unsicher, auf welcher Sprosse Ihre Idee liegt? Der Entscheidungsbaum unten liefert Ihnen die Antwort mit höchstens drei Fragen.

Schickt der Baum Sie zu einem Entwickler, war der Prototyp nicht umsonst. Ein funktionierender Mock-up plus Spezifikation ist das klarste Briefing, das ein Entwickler bekommen kann.

Die Sicherheits-Checkliste vor dem Launch

Gehen Sie sie durch, bevor jemand außerhalb Ihrer Testkonten einen Link bekommt. Nichts davon setzt voraus, dass Sie Code lesen. Jeder Punkt ist eine Einstellung zum Nachsehen, ein Scan zum Ausführen oder ein Test zum Durchspielen.

Zwei Punkte leisten die Hauptarbeit. Row-Level-Security auf jeder Tabelle prüfen Sie in der Datenbank- oder Sicherheitsansicht Ihres Builders, und Bolt markiert Regeln, die „always true" sind, also jeden hereinlassen. Der Test mit dem zweiten Konto fängt ab, was Scanner übersehen, etwa die verkehrt herum geschriebene Zugriffsprüfung in der Lovable-App oben.

Der Rest ist schnell erledigt. Bolt aktiviert den Schutz vor geleakten Passwörtern standardmäßig, und Lovables Scan vor der Veröffentlichung meldet es, wenn er deaktiviert ist. In Lovable landet alles mit dem Präfix VITE_ im Browser, ein geheimer Schlüssel darf es also nie tragen.

Scans haben Grenzen, und die Anbieter sagen das auch. Lovables Dokumentation schreibt, die Tools „cannot guarantee complete security", und empfiehlt für Apps mit sensiblen Daten eine professionelle Prüfung. Die Dokumentation von Base44 ist kürzer: Sie sind für die Sicherheitseinstellungen Ihrer App selbst verantwortlich.

Das Projekt an einen Entwickler übergeben

Eine Vibe-Coding-App, die funktioniert, braucht früher oder später einen Entwickler, der sie prüft oder übernimmt. Planen Sie die Übergabe von Anfang an mit.

Verbinden Sie früh ein GitHub-Repository. Lovables Zwei-Wege-Sync funktioniert in jedem Tarif, und ein Entwickler kann das Repository klonen und im eigenen Editor weiterarbeiten. Base44s Zwei-Wege-Sync beginnt mit dem Builder-Tarif. In v0 wird ein verbundenes Repository zur maßgeblichen Quelle, und v0 pusht seine Änderungen auf einen Arbeits-Branch statt direkt auf den Branch, von dem es ausging. Auch Bolt synchronisiert Commits mit GitHub.

Wissen Sie, was der Code zurücklässt. Laut Lovables Dokumentation enthalten weder der Git-Sync noch ein Code-Download die Daten in Ihrer Datenbank, und die Anleitung zum Hosting anderswo lässt Sie Speicherdateien von Hand verschieben. Base44 sagt, nichts sei an die Plattform gebunden und der GitHub-Sync exportiere den vollständigen Quellcode. Die Entwicklerdokumentation beschreibt außerdem ein SDK, über das exportierte Projekte auf Base44s eigene Dienste für Daten und Backend-Funktionen zugreifen. Unsere Einschätzung, nicht Base44s Aussage: Ein kompletter Umzug weg von Base44 kann bedeuten, diese Schicht zu ersetzen.

Geben Sie dem Entwickler ein kurzes Übergabepaket mit:

• Der Spezifikation, mit jedem Screen und wer ihn nutzen darf.
• Zugang zum Repository und zum Builder-Projekt.
• Einer Liste in einfachem Deutsch, welche Tabellen es gibt und wer sie lesen und ändern dürfen soll.
• Den hinzugefügten Integrationen und den Namen der dafür genutzten Secrets, niemals den Werten selbst im Chat oder per E-Mail.
• Bekannten Bugs, allen seltsamen Workarounds, die Sie per Prompt eingebaut haben, und dem, was das Projekt bisher an Credits gekostet hat.

Bitten Sie vor neuen Features um ein Security-Review: Zugriffsregeln, serverseitige Funktionen und wo die Secrets liegen. Die meisten Entwickler öffnen das Repository in einem Coding-Tool wie Cursor oder Claude Code. Unser Überblick über Coding-Assistenten und der Beitrag KI-Coding-Assistenten vs. Agent-Builder erklären, wie sich diese Tools von App-Buildern unterscheiden, und das Ranking der KI-Coding-Assistenten ordnet das Feld ein.

Häufig gestellte Fragen

Gehört mir der Code, den ein Vibe-Coding-Tool schreibt?

Lovable, Base44, Bolt und v0 synchronisieren Code alle mit einem GitHub-Repository, das Sie kontrollieren, Base44 ab dem Builder-Tarif. Den Code zu besitzen ist aber nicht dasselbe, wie die laufende App zu besitzen. Ihre Daten, gespeicherten Dateien und Backend-Dienste können auf der Plattform bleiben, bis jemand sie migriert.

Welches Vibe-Coding-Tool ist für den Einstieg am günstigsten?

Alle fünf haben einen kostenlosen Tarif. Lovable gibt kostenlosen Nutzern 5 Build-Credits pro Tag, gedeckelt bei 30 im Monat, und Replits Free Mode läuft in den kostenlosen und bezahlten Einzeltarifen, mit Limits je nach Tarif. Bei den bezahlten Tarifen ist Base44s Starter mit 16 $ im Monat bei jährlicher Zahlung gelistet und Replit Core mit 20 $ im Monat.

Kann ich in einer Vibe-Coding-App Zahlungen annehmen?

Ja, über einen gehosteten Checkout. Lovables Stripe-Integration öffnet Stripe Checkout und speichert Ihren geheimen Schlüssel als Backend-Secret, nicht im Code der App. Testen Sie zuerst mit Sandbox-Schlüsseln und Stripes Testkarte. Nutzungsabrechnung, Auszahlungen an andere Nutzer und Abrechnung für Konten mit mehreren Unternehmen sind Sache von Entwicklern.

Kann die KI ihren eigenen Code auf Sicherheit prüfen?

Teilweise. Integrierte Scans finden häufige Probleme wie fehlende Zugriffsregeln, offene Schlüssel und verwundbare Pakete. Aber die Anbieter sagen selbst, dass Scans keine Sicherheit garantieren können, und die App, die 18.697 Datensätze preisgab, lief auf einer Plattform mit kostenlosem Scan vor der Veröffentlichung. Betrachten Sie den Scan als Untergrenze, nicht als Freigabe.

Was ist mit Firebase Studio passiert?

Google stellt es ein. Es legt keine neuen Workspaces mehr an, schließt 2027, und Google rät Nutzern, bestehende Workspaces zu Google AI Studio oder Antigravity zu migrieren. Firebase-Dienste wie Firestore und Authentication laufen wie bisher weiter.