Dein Bolt.new-Projekt funktioniert — jetzt wird es zur SaaS

Bolt.new ist eine KI-gestützte Full-Stack-Web-IDE von StackBlitz, die aus Prompts komplette Webanwendungen (HTML, CSS, JavaScript, Backend, optional Datenbank) generiert und direkt im Browser ausführt. Für Validierung, Demo-Loops und «schnell zeigen, was ich im Kopf habe» reicht das.

Irgendwann willst du aber live gehen. Echte Nutzer. Echte Daten. Echte Zahlungen. Genau hier wird es heikel. Bolt läuft in einem WebContainer, also einer Sandbox im Browser. Das ist gut für schnelle Entwicklung, aber nicht für den Live-Betrieb. Die Daten-Persistenz ist temporär, die Skalierung begrenzt und die Sicherheit nicht gehärtet.

Wir bauen daraus eine echte SaaS. Mit echtem Hosting, echter Datenbank, echter Sicherheit. In vier bis acht Wochen.

Stärken und Grenzen

Was Bolt.new kann — und wo es endet

Bolt ist sehr schnell. Die Stärken:

  • WebContainer-basiert: Der Code läuft direkt im Browser, keine Installation.
  • Vollständige Stack-Generierung: HTML, CSS, JavaScript, sogar einfache Node- oder Express-Backends.
  • Live-Vorschau: Du siehst Änderungen sofort. Bearbeiten, neu laden, fertig.
  • Schnelle Iterationen: Per Prompt Feedback geben, ohne Git und ohne Build.
  • Stark als Prototyp: Für Pitch, Validierung und MVP-Test ideal.

Wo Bolt an Grenzen stösst:

  • Keine echte Datenbank-Persistenz: WebContainer brauchen ein echtes Backend (Supabase, Firebase oder ähnliches) oder lokalen Speicher. Das ist fragil.
  • StackBlitz-Hosting ist Sandbox: Live-Betrieb ist auf StackBlitz nicht vorgesehen. Du brauchst eigenes Hosting (Vercel, AWS, Netlify).
  • Hoher Token-Verbrauch: Bei komplexen Features oder beim Suchen nach Fehlern dreht die KI schnell Schleifen, drei bis acht Millionen Tokens für einen einzelnen Authentifizierungs-Bug sind dokumentiert.
  • Rund 70 Prozent der Lösung: Erfahrungswerte zeigen: Bolt bringt dich etwa 70 Prozent ans Ziel. Die letzten 30 Prozent musst du selbst bauen.
  • Keine echte Mehrkundenfähigkeit: Bolt generiert Single-Tenant. Workspace, Mandantentrennung, RLS müssen manuell ergänzt werden.
  • Aufräumen nötig: WebContainer-Code enthält oft viel Boilerplate, doppelte Importe und keine etablierten Patterns.
Die Lücken

Typische Lücken in einem Bolt-Prototyp

01
Daten-Persistenz ist fragwürdig

Bolt kann Supabase oder Firebase einbinden, aber: API-Schlüssel landen oft im Code statt in .env. Datenbank-Queries sind nicht optimiert. Pagination fehlt, bei 10’000 Zeilen wird alles geladen. Folge: Beim Live-Gang Daten weg, API-Kosten steigen stark.

02
WebContainer-Hosting-Limits

Bolt läuft auf StackBlitz, mit klaren Grenzen: Maximale Request-Grösse rund 1 MB. Maximale Ausführungszeit rund 30 Sekunden. Keine Persistenz: Daten sind nach einem Browser-Reload weg, wenn sie nicht in einem externen Backend liegen. Folge: Du schaltest den Bolt-Prototyp auf einer Live-URL frei und bekommst bei echten Nutzern Abstürze.

03
Keine getrennten Umgebungen

Entwicklung und Live-Betrieb laufen am gleichen Ort. Deine Tests überschreiben echte Kundendaten. Folge: Ein Bug-Fix gemacht und alle Produktivdaten sind beschädigt.

04
Stripe-Anbindung lückenhaft

Bolt kann Stripe-Buttons bauen, aber: Die Webhook-Verarbeitung ist nicht produktionsreif. Wiederkehrende Abos sind nicht robust gebaut. Fehlerbehandlung («Was passiert, wenn der Webhook drei Sekunden später ankommt?») fehlt. Folge: Zahlungen sind unsicher, Rechnungen stimmen nicht.

05
Sicherheit nur an der Oberfläche

CORS zu offen konfiguriert. XSS-Schutz fehlt. SQL-Injection möglich, wenn du direkt SQL formulieren lässt. Secrets im Frontend-Code. Folge: Beim ersten Security-Audit zweistellige Anzahl kritischer Lücken.

06
Performance unter Last

Bolt generiert nicht mit Live-Performance im Kopf. Kein Caching, keine Datenbank-Indexierung, keine API-Optimierung. Folge: Bei 100 gleichzeitigen Nutzern Antwortzeiten von 8 bis 15 Sekunden.

So arbeiten wir

In drei Phasen vom Prototyp zur SaaS

01

Code-Analyse

1 bis 2 Wochen, kostenlos
  • Hosting-Strategie: Bei Node/Express bleiben oder auf Next.js bzw. Remix migrieren?
  • Datenbank-Design: Ist die Struktur tragfähig? Brauchen wir Migrations-Werkzeuge?
  • Stripe und Bezahlung: Wie robust ist die Zahlung?
  • Performance-Hotspots: Welche API-Aufrufe sind teuer, welche Queries langsam?
  • Sicherheit: RLS? CORS? XSS-Schutz?
  • Du bekommst eine Risiko-Übersicht, einen Migrationsplan, eine Kostenschätzung und einen Zeitplan.
02

Sicher und betreibbar machen

4 bis 8 Wochen
  • Auf echtes Hosting migrieren: Vom StackBlitz-WebContainer zu Node/Express oder Next.js auf Vercel, AWS, Netlify oder eigenem Server. Daten aus Bolt übernehmen, falls nötig.
  • Datenbank härten: Schema validieren und optimieren, Indizes für häufige Queries, Connection Pooling, automatisierte Backups.
  • Sicherheit zuerst: Secrets in Umgebungsvariablen, CORS sauber, XSS-Schutz, SQL-Injection verhindern, Rate-Limits, Authentifizierung mit Session und JWT.
  • Stripe robust: Webhooks idempotent mit Wiederholungslogik, Abo-Flows mit Upgrade/Downgrade/Kündigung, Rechnungen mit Schweizer Mehrwertsteuer, anteilige Abrechnung.
  • Getrennte Umgebungen: Dev, Staging, Live mit getrennten Datenbanken und Stripe-Konten. Git-Branches und CI/CD-Pipeline.
  • Performance: Caching auf Browser-, API- und Datenbank-Ebene, CDN für statische Assets, Lazy Loading, Connection Pooling.
  • Überblick im Betrieb: Fehlerverfolgung, Performance-Monitoring, Log-Aggregation, Alarme bei auffälligen Fehlerquoten.
  • Dokumentation: Architektur-Diagramme, API-Dokumentation, Datenbank-Schema, Deployment-Runbook.
03

Wachsen und mitskalieren

laufend
  • Monitoring: Antwortzeit, Fehlerrate, API-Kosten im Blick.
  • Updates: Neue Framework-Versionen integrieren.
  • Roadmap: Neue Anforderungen analysieren, priorisieren, bauen.
  • Kosten optimieren: Bei zehnfacher Nutzerzahl andere Strategien.
Heuristik

Wann lohnt sich Härtung, wann Neuaufbau?

Härtung passt, wenn:

  • Dein Bolt-Code ist inhaltlich sauber (Logik funktioniert).
  • Die Datenbankstruktur ist tragfähig (nicht perfekt, aber ausreichend).
  • Keine grundsätzlichen technischen Schulden (zum Beispiel kein komplett verworrener Node-Server).
  • Das Framework passt für dich (bei Node/Express bleiben oder auf Next.js heben).

Aufwand: CHF 10000 bis 40000, häufig 4 bis 6 Wochen. Du hast danach ein Hosting- und Sicherheits-Setup, das besser für den Betrieb geeignet ist.

Neuaufbau ist besser, wenn:

  • Dein Bolt-Code ist verworren, das Routing unklar, das State-Management kaputt.
  • Die Datenbankstruktur ist grundsätzlich falsch.
  • Dein Produkt ist zu komplex für den Bolt-Output (Echtzeit-Features, umfangreiche Workflows, Mobile-Apps).
  • Du brauchst eine andere Sprache oder ein anderes Framework (Python, Go, Rust).

Aufwand: CHF 80000 bis 300000, 8 bis 16 Wochen. Dafür höhere Code-Qualität und bessere Flexibilität.

Preisrahmen

Was kostet die Bolt-Härtung?

Code-Analyse
Kostenlos

Schriftlicher Bericht, Migrationsplan und Härtungs-Plan. 1 bis 2 Wochen.

Härtung (Standard)
CHF 10’000 bis 40’000

Für Bolt-Prototypen mit klarer Struktur. 4 bis 6 Wochen. Hosting, Datenbank, Sicherheit, Stripe, Überblick im Betrieb.

Härtung (komplex)
CHF 40’000 bis 80’000

Für grössere Bolt-Projekte mit komplexen Anbindungen. 6 bis 8 Wochen.

Neuaufbau
CHF 80’000 bis 300’000

Wenn zu viel von Grund auf neu gebaut werden muss. 8 bis 16 Wochen.

Betrieb und Weiterentwicklung
Monatlich skalierbar

Wir managen Infrastruktur, Wartung, Sicherheit, Updates und Skalierung. Der Kunde kann weiter vibecoden und neue Features erfinden; wir prüfen, härten und mergen sie kontrolliert über klare Regeln und eine saubere Pipeline in den produktiven Betrieb. Die monatlichen Kosten wachsen mit Nutzung und Anspruch, damit der Start auch mit wenigen Usern tragbar bleibt.

FAQ

Häufige Fragen zu Bolt und SaaS

Kann ich meinen Bolt-Code direkt auf Vercel deployen?

Manchmal direkt, oft mit Anpassungen. Bolt arbeitet im StackBlitz-WebContainer; Produktionsplattformen wie Vercel, Netlify, Render oder Google Cloud haben andere Annahmen zu Build, Umgebungsvariablen und Laufzeit. Wir prüfen den Code und passen ihn so an, dass Deployment, Caching und Betrieb zuverlässig funktionieren.

Meine Daten liegen jetzt in Bolt bzw. StackBlitz, wie kommen die raus?

StackBlitz hat keine eingebaute Datenbank-Export-Funktion. Wir können Daten direkt aus der angebundenen Datenbank (Supabase, Firebase) exportieren. Oder ein Skript schreiben, das lokale Daten (zum Beispiel aus dem localStorage) exportiert und in eine echte Datenbank importiert. Wenige Tage Arbeit, Teil der Härtung, im Paket-Preis enthalten.

Bleibt der Stack (Node/Express), oder wechselt ihr?

Das besprechen wir in der Code-Analyse. Node oder Express sind völlig in Ordnung, dann härten wir das. Wenn dein Workload mehr verlangt, schlagen wir Next.js oder Remix vor (klarere Konventionen, bessere Entwickler-Experience, bessere Skalierung). Dein Code bleibt portierbar. Kein Lock-in.

Was, wenn ich Bolt später nochmal nutzen möchte?

Kein Problem. Dein Bolt-Code bleibt dein Code. Du kannst weiterhin in StackBlitz arbeiten und neue Features per Prompt erkunden. Wir integrieren das neue Feature dann in deinen produktiven Code. Es ist also nicht «Bolt oder Härtung», sondern «Bolt und Härtung». Bolt bleibt dein Prototyping-Werkzeug.

Wie robust ist Stripe bei euch?

Wir implementieren Stripe nach bewährten Mustern: Webhooks mit Signaturprüfung, Idempotenz gegen doppelte Events, saubere Fehlerbehandlung, Rechnungslogik und Mehrwertsteuer-Prüfung. Welche Details nötig sind, hängt von Abo-Modell, Ländern und Buchhaltungsprozess ab.

Wie lange dauert die Umstellung vom Bolt-WebContainer zu echtem Hosting?

Für überschaubare Projekte oft 1 bis 2 Wochen als Teil der Härtung. Es hängt davon ab: Wie komplex ist dein Code? Gibt es Abhängigkeiten zu StackBlitz-Features, die woanders nicht existieren? Wie viele Tests braucht ihr? Wir streben einen Wechsel mit Parallel-Setup und Rückfall-Plan an; ob ein unterbruchsfreier Wechsel realistisch ist, prüfen wir im Einzelfall.

Unterstützt ihr auch nach dem Launch?

Wir sind von Anfang an für dich da und wollen, dass du langfristig erfolgreich bist. Optional begleiten wir Betrieb und Weiterentwicklung — monatlich skalierbar, Umfang nach Nutzung und Anspruch. So bleibt der Start auch mit wenigen Usern tragbar. Ohne laufende Wartung können nach ein paar Wochen wieder Probleme entstehen: veraltete Abhängigkeiten, unsaubere Feature-Merges, Sicherheitslücken oder steigende Betriebskosten.

Was ist, wenn ich Token-intensive Bugs habe?

Das sehen wir bei KI-Buildern regelmässig: Der Agent versucht lange zu reparieren, obwohl ein erfahrener Blick schneller wäre. Wir prüfen solche Bugs manuell, isolieren die Ursache und entscheiden dann, ob ein gezielter Fix oder ein kleiner Umbau sinnvoller ist.

Bereit, deinen Bolt-Prototyp ernsthaft zu machen?

Schick uns deinen Bolt-Code (.zip oder Live-Demo auf StackBlitz). Wir analysieren ihn kostenlos und schicken dir einen schriftlichen Bericht und einen klaren Plan für die Härtung.