Bolt.new to Production: The Complete Deploy Checklist

The 70% Problem

There's a phenomenon in vibe coding circles called the "70% problem":

AI can get you 70% of the way to a working application remarkably fast. But the last 30%—the edge cases, the error handling, the production hardening—requires significant manual work.

Bolt.new is a prime example. It's genuinely impressive for building prototypes. You describe what you want, it generates a full-stack app, you can preview it immediately.

But "preview works" is not "production ready."

What Bolt Does Well

Credit where it's due:

• Rapid prototyping - Idea to working demo in minutes
• Full-stack generation - Frontend and backend together
• Real-time preview - See changes immediately
• Decent code quality - Usually follows React best practices

For getting started, exploring ideas, or building internal tools: Bolt is great.

What Bolt Doesn't Handle

Based on user reports and reviews, here's where Bolt struggles:

Bug Recurrence

Users report that bugs they fixed sometimes reappear when they regenerate or modify the app. Bolt doesn't have traditional version control, so there's no reliable way to track what changed or roll back.

Context Limits

Once projects exceed 15-20 components, Bolt starts losing context. It forgets decisions made earlier. Consistency degrades. Token usage spikes.

Complex State Management

If your app needs sophisticated state handling—real-time updates, complex forms, authentication flows—you'll likely be fighting Bolt rather than flowing with it.

Debugging Costs

Some users report spending $1,000+ in tokens just fixing issues. Unlike traditional development with flat pricing, Bolt's token model means debugging can get expensive fast.

The Production Checklist

Before deploying a Bolt-built app to real users, check these:

1. Environment Variables

Check:

• Are secrets actually in environment variables (not hardcoded)?
• Does your hosting platform have them configured?
• Do local dev values differ from production values?

Common Bolt issue: Generated code sometimes includes placeholder API keys that look real.

2. Error Handling

Check:

• What happens when an API call fails?
• What do users see when something breaks?
• Are errors logged somewhere you can find them?

Common Bolt issue: Happy path works great. Error paths are often undefined or crash ungracefully.

3. Database Security

If using Supabase (common with Bolt):

• Is RLS enabled on all tables?
• Do policies actually restrict access appropriately?
• Can unauthenticated users access data they shouldn't?

See our post on Lovable security—same issues apply to any vibe-coded Supabase integration.

4. Authentication Flows

Check:

• Can users actually log in/out?
• What happens with password reset?
• Are sessions persisted correctly?
• What happens if someone mashes the login button?

Test: Walk through every auth flow manually. Pretend you're a confused user.

5. Input Validation

Check:

• What happens with empty form submissions?
• What about extremely long inputs?
• Special characters?
• What if someone pastes a script tag?

Common Bolt issue: Forms often accept anything and let the database figure it out.

6. Mobile Responsiveness

Check:

• Does it work on actual phones (not just small browser windows)?
• Are touch targets large enough?
• Does the keyboard not cover input fields?

Test: Actually use it on your phone. Not just the simulator.

7. Loading States

Check:

• When data is loading, what does the user see?
• If loading takes 10 seconds, will they understand why?
• Is there feedback on button clicks?

Common Bolt issue: Instant data in development. Slow data in production. No loading indicators.

8. External Services

Check:

• What if Supabase is slow?
• What if a third-party API is down?
• Are there rate limits you might hit?
• Are connections timing out gracefully?

9. SEO Basics (If Public-Facing)

Check:

• Does each page have a unique title?
• Are meta descriptions set?
• Is there an OG image for social sharing?
• Can search engines crawl it?

10. Monitoring

Check:

• Will you know if the site goes down?
• Will you know if errors spike?
• Can you see what real users are experiencing?

If the answer is "I'll find out when users complain," you're not ready for production.

The Deployment Process

Step 1: Export and Review

Don't just deploy from Bolt directly. Export the code. Look at it. Does it make sense?

Step 2: Local Testing

Run the app locally. Click everything. Break things on purpose.

Step 3: Staging Environment

Deploy to a staging URL first. Share with a few people. Watch for issues.

Step 4: Production Deploy

Once staging is stable, deploy to production.

Step 5: Post-Deploy Monitoring

Set up uptime monitoring immediately after deploy. Watch for errors in the first 24 hours.

When to Not Use Bolt for Production

Be honest with yourself. Bolt might not be the right tool if:

• You're building something complex - Enterprise features, sophisticated auth, real-time collaboration
• You're handling sensitive data - Medical, financial, personal information
• You need version control - Tracking changes, rolling back, multiple developers
• You're expecting scale - Thousands of users, high traffic

Bolt is excellent for:

• MVPs and prototypes
• Internal tools
• Simple CRUD apps
• Learning and experimentation

The Handoff Decision

At some point, a successful Bolt app may outgrow Bolt. Signs you need to hand off to traditional development:

• You're spending more time fighting Bolt than building features
• Token costs are outpacing development progress
• You need features Bolt can't generate reliably
• The codebase is getting too complex for Bolt's context

The handoff doesn't mean failure. It means your idea succeeded and needs more robust infrastructure.

The Bottom Line

Bolt.new is a fantastic tool for a specific phase of development. It's not magic. It has limits.

Use the checklist above before going live. Your users will thank you.

---

SlyDuck monitors Bolt-built apps in production. Know when things break—before users tell you.