For Bolt.new apps

Bolt apps demo cleanly. They break when real users hit them.

Bolt.new optimizes hard for "working in the next sixty seconds." The same patterns that make it fast also produce code that ships without migrations, without signed webhooks, and without rate limits. None of these matter in a demo. All of them matter the moment your app touches real money or real users.

Book a free audit
§ I. Patterns

What we read for in Bolt apps.

Bolt's failure modes lean toward production-readiness rather than pure security. The app works. It just isn't ready for what comes after the demo.

  1. 01

    Unsigned-webhook default

    CRIT

    Bolt's Stripe webhook handlers parse request.json() and trust the body. Anyone can flip orders to paid or grant themselves subscriptions with a single curl command.

  2. 02

    No migration history

    HIGH

    Schemas live inline in code or in hand-edited Supabase UI changes. No migration table, no rollback path, no safe way to deploy a schema change once you have real users.

  3. 03

    Dev URLs that shipped to production

    HIGH

    localhost:3000 and Supabase preview URLs hard-coded in environment configs end up in production builds. Webhooks fire to dead endpoints; you find out from confused customers.

  4. 04

    N+1 queries in dashboard loops

    MED

    Bolt generates loops that hit the database once per item. Fine at ten rows. Times out at a thousand. Performance degrades silently as you grow.

  5. 05

    Unmetered AI endpoints

    HIGH

    If your app calls OpenAI or Anthropic on user request, Bolt almost never adds rate limiting. One bad actor, or one accidentally-public form, runs your AI bill to four figures in an afternoon.

  6. 06

    Stack traces in error responses

    MED

    Caught errors return full stack traces to the client. Database table names, file paths, env var names: all visible to anyone hitting a broken endpoint.

6 patterns 1 critical 3 high 2 medium
§ II. Root cause

Why Bolt ships these patterns.

Bolt is excellent at prototyping and predictably weak at the slower work of production: migrations, observability, rate limits, idempotency. None of these show up in a demo, so none of them get prompted. The tool is honest about what it is: it gets you to a working app in an afternoon, and that's the job.

The Fix Sprint covers the production gaps in roughly the order they'll hurt you. We start with the issues that can lose money (unsigned webhooks, missing idempotency, unmetered AI) and work down to the ones that just slow you down (N+1 queries, missing indexes).

None of these matter in a demo. All of them matter the moment your app touches real money or real users.

Bolt audit notes
§ III. Honest limits

What this approach won't catch.

We audit the gap between "prototype" and "ready for real users." If you're past that point and looking for an architectural review (a database schema rewrite, a multi-region failover plan, a serious performance overhaul), that's bigger than what we do here. We'll say so on the call.

Book a free audit for your Bolt app