In der letzten Lektion hast du die Trennlinie zwischen Artefakt und Produkt gesehen. Vielleicht denkst du jetzt: „OK, aber Lovable / Bolt / Replit machen doch genau das — die deployen mein Ding, geben mir eine URL, und ich besitze die App."
Das stimmt — für den Moment, an dem du das Tutorial-Video schaust. Für drei Wochen später meistens nicht mehr. In dieser Lektion gehts um die drei Probleme, die in jedem Demo-Video weggelassen werden — damit du selbst entscheidest, wann ein SaaS-Baukasten passt und wann nicht.
Was diese Tools versprechen
Lovable, Bolt, Replit Agent, Base44, v0 — sie alle bieten dasselbe Konzept an:
- Du tippst eine Idee in deutscher oder englischer Sprache.
- Sie erzeugen Frontend, Backend, Datenbank, Auth, Hosting.
- Du klickst auf „Publish", kriegst eine URL, fertig.
Auf dem ersten Blick: magisch. Auf den zweiten Blick: drei strukturelle Probleme, die nicht weggehen, egal wie gut das Modell wird.
Problem 1: Du besitzt den Code nicht — oder zumindest nicht so, dass du ihn benutzen kannst
Bei Lovable, Bolt & Co. läuft dein Code in deren Infrastruktur. Manchmal kannst du den Source-Code exportieren — als ZIP oder GitHub-Repo. Aber: er ist meist eng mit deren proprietärem Stack verknotet. Eigene Auth-Logik der Plattform, eigene Datenbank-Klassen, eigene Deploy-Schicht.
Was heißt das praktisch? Wenn die Plattform deine Preise verzehnfacht, du den Anbieter wechseln willst, oder das Unternehmen einfach pleite geht — dann kannst du den exportierten Code zwar herunterladen, aber er läuft nirgendwo anders ohne Tage Refactoring.
Das ist nicht böse Absicht der Anbieter. Das ist die natürliche Konsequenz davon, dass sie Convenience verkaufen — und Convenience funktioniert nur, wenn alles an einer Stelle ist.
Code, Datenbank, Auth, Hosting, Deploy — alles aus einer Hand. Schnell oben, leicht zu starten.
Aber: Wenn dir der Anbieter morgen den Stecker zieht oder die Preise verdreifacht, ist der Umzug ein Vollzeit-Projekt. Du baust auf gemietetem Grund.
Code, Datenbank, Auth, Hosting, Deploy — alles aus einer Hand. Schnell oben, leicht zu starten.
Aber: Wenn dir der Anbieter morgen den Stecker zieht oder die Preise verdreifacht, ist der Umzug ein Vollzeit-Projekt. Du baust auf gemietetem Grund.
Next.js + Supabase + Vercel + GitHub — vier unabhängige Werkzeuge, die jedes für sich tauschbar sind. Mehr Setup-Aufwand am Anfang.
Dafür: Wenn Vercel teurer wird, ziehst du auf einen anderen Hoster um. Wenn du Supabase rauswerfen willst, läuft Postgres überall. Du bestimmst die Spielregeln.
Problem 2: Kosten skalieren absurd
Die Preisseiten zeigen dir 19 USD/Monat. Das ist der Hobby-Plan — gut für drei Seiten und 1000 Besuche pro Monat. Sobald irgendetwas Reales darauf läuft, wird es interessant.
Reale Zahlen aus der Community (Stand 2026, Sommer):
- Lovable Free → 5 Generierungen/Tag, ab da kostet es.
- Lovable Pro 25 USD/Monat → ~250 Token-Generierungen/Monat. Bei aktiver Iteration ist das eine Woche.
- Lovable Scale 250 USD/Monat → eher etwas, wenn du es geschäftlich nutzt.
- Bolt 20 USD/Monat → 10 Mio Tokens, die bei größeren Apps in zwei Tagen weg sind.
- Replit Hobby 25 USD/Monat → eingeschränkt; Production-Tier startet bei 25–40 USD plus Compute-Kosten on top.
Wenn dein Produkt erfolgreich wird, multipliziert sich das. Bei Eigen-Stack zahlst du Hosting-Kosten (Vercel Hobby kostenlos, Pro 20 USD), DB-Kosten (Supabase 25 USD Pro, vorher gratis), AI-API-Kosten (das, was du Claude/OpenAI tatsächlich gibst — bezahlst du eh, egal ob via SaaS oder direkt). Aber: du zahlst keine Plattform-Marge obendrauf.
Faustregel: Sobald deine App mehr als 100 reale Nutzer:innen hat, ist der eigene Stack günstiger. Davor: schwankt.
Problem 3: Production-Reife fehlt — und das merkst du erst, wenn es weh tut
Das ist der unsichtbarste Punkt — und der teuerste. Lovable & Co. bauen sehr gute Demos. Aber Production heißt:
- Echte Auth mit Magic-Link / OAuth / Session-Refresh, nicht nur „Email + Passwort lokal speichern".
- Webhook-Idempotenz — wenn Stripe deinen Webhook zweimal feuert (passiert), darf dein Kunde nicht zweimal Premium bekommen oder die Datenbank nicht doppelt schreiben.
- Row-Level-Security auf der Datenbank — Nutzer A sieht NIE Nutzer Bs Daten, egal welche fehlerhafte Query du schreibst.
- Echte Tests (Unit + E2E), die jeden Push prüfen, ob etwas kaputt ist.
- Sentry / Error-Tracking, damit du am Sonntag um 4 Uhr morgens merkst, dass deine App seit drei Stunden weiße Seiten ausliefert.
- Rate-Limiting, damit ein einzelner böser Nutzer dich nicht in eine 500-USD-AI-Rechnung schubsen kann.
- GDPR-Compliance — Datenexport, Account-Löschung, Audit-Trail.
Nichts davon liefert ein SaaS-Baukasten in der Standard-Form. Manche haben Add-ons (oft teuer), aber sie sind nie das Default. Wenn du ein Hobby-Demo baust: egal. Sobald reale Nutzer:innen mit echten Daten drauf sind: blocker.
Wann sie trotzdem die richtige Wahl sind
Es gibt drei Fälle, in denen SaaS-Baukästen sinnvoll sind — bewusst gewählt, nicht aus Unwissen:
- Wegwerf-Prototyp für ein Investoren-Pitch oder ein Mockup-Meeting. Lebt eine Woche, dann ist es weg.
- Mood-Board / Click-Dummy für UI-Diskussionen. Du willst nicht Code, du willst eine sichtbare Variante.
- Hackathon-Demo in 8 Stunden bauen. Da geht es nicht um Wartbarkeit, sondern um den ersten Bildschirm.
In allen drei Fällen: super. Hol dir das Tool, dass am schnellsten am Ziel ist. Drei Tage später ist es egal.
Aber alles, was länger als drei Monate lebt oder echte Nutzerdaten enthält — eigener Stack. Nicht weil SaaS-Tools schlechter sind, sondern weil Besitz der Faktor ist, der über sechs Monate hinaus zählt.
Was dieser Kurs stattdessen liefert
Wir bauen mit deinem eigenen Stack — Next.js + Supabase + Vercel + Stripe + Claude Code. Vier davon (alle außer Claude) sind klassische Web-Tools, die seit Jahren etabliert sind. Du besitzt den Code, du kannst jederzeit den Anbieter wechseln, und du lernst Patterns, die in echten Produktions-Apps drinstecken.
Das ist langsamer als „App in 20 Minuten" — aber es führt zu etwas, das in 20 Monaten noch da ist und in 200 noch wachsen kann.