From Bolt.new Prototype to Production in 2 Weeks

A founder came to us with a SaaS product built almost entirely with Bolt.new and Claude. He'd spent three weeks building it — an impressive project management tool for creative agencies. The UI was polished. The demo was convincing. He had five paying beta users.

He also had a launch date in three weeks and a growing suspicion that his app wasn't ready for real traffic.

He was right.

Note: Client details have been anonymized. The technical findings are real.

The Challenge

The founder — let's call him Tomas — is a former project manager at a creative agency. He knew the problem space cold. He used AI tools to build a solution that actually worked for his use case. The product logic was solid.

But Tomas isn't an engineer. He couldn't tell the difference between code that works in a demo and code that works under load. He had a few warning signs:

• The app occasionally showed blank pages that went away on refresh
• Loading times were getting slower as beta users added more data
• One user reported seeing another user's project name flash briefly during page load
• He had no idea what would happen with 50 or 100 concurrent users

That last point was the one that brought him to us.

What We Found

We ran our standard Quick Audit — a comprehensive review of security, performance, infrastructure, and code quality. Here's what the audit uncovered:

Security: 23 Issues

• 4 critical: API keys hardcoded in client-side JavaScript (including Stripe secret key), no server-side authorization on API routes (any authenticated user could access any project), open CORS policy (*), and an admin route with no authentication
• 8 high: No input validation on any endpoint, missing rate limiting, SQL queries built with string concatenation in 3 places, session tokens stored in localStorage
• 11 medium: Missing security headers (CSP, HSTS, X-Frame-Options), no audit logging, passwords hashed with MD5 instead of bcrypt, no CSRF protection

The user seeing another user's project name? That was the missing authorization. Any logged-in user could fetch any project's data by guessing the ID (which was a sequential integer).

Performance: 4x Slower Than Acceptable

• N+1 queries everywhere — the project list page made 47 database queries for 15 projects
• No caching — every page load hit the database for data that changed once a day
• No connection pooling — each request opened a new database connection
• Unoptimized images — user-uploaded images served at original resolution (some were 5MB+)
• No CDN — static assets served from the application server in Frankfurt

Average page load: 4.2 seconds. After our fixes: 0.9 seconds.

Infrastructure: Single Point of Failure

• One server, no redundancy — if the VPS went down, everything went down
• No automated backups — the database had never been backed up
• No monitoring — Tomas found out about downtime when users emailed him
• Deployments by SSH — git pull && npm run build on the production server, with no rollback plan
• No staging environment — all testing happened in production

Code Quality

The AI-generated code was actually well-structured for a prototype. Components were reasonably organized, naming was consistent, and the business logic was sound. The problems were all in the areas AI tools don't prioritize: security, performance under load, and operational readiness.

What We Fixed

We worked with Tomas over two weeks, prioritizing by risk. Here's what we did, in order:

Week 1: Security and Critical Infrastructure

Day 1-2: Security hardening

• Moved all secrets to environment variables and a .env file excluded from git
• Rotated the exposed Stripe key and all database credentials
• Added server-side authorization checks on every API route
• Configured CORS to only allow the production domain
• Protected the admin route with authentication and IP restriction

Day 3-4: Input validation and data protection

• Added Zod validation schemas for every API endpoint
• Replaced string-concatenated SQL with parameterized queries
• Migrated password hashing from MD5 to bcrypt (with migration path for existing users)
• Moved session tokens from localStorage to httpOnly cookies
• Added rate limiting on authentication endpoints

Day 5: Infrastructure basics

• Set up automated daily database backups to offsite storage
• Added uptime monitoring (Better Stack) and error tracking (Sentry)
• Created a staging environment mirroring production
• Set up a basic CI/CD pipeline: push to main runs tests and deploys automatically

Week 2: Performance and Operational Readiness

Day 6-7: Database optimization

• Fixed all N+1 queries with eager loading — 47 queries per page down to 3
• Added database indexes on frequently queried columns
• Set up connection pooling with PgBouncer
• Added application-level caching with Redis for frequently accessed data

Day 8-9: Frontend performance

• Implemented image optimization pipeline (resize, compress, serve WebP)
• Added CDN for static assets (Cloudflare)
• Implemented proper caching headers
• Code-split the main bundle — initial load dropped from 1.8MB to 340KB

Day 10: Final hardening

• Load tested with 200 concurrent users — stable at 150ms average response time
• Added health check endpoint for the load balancer
• Set up PM2 with auto-restart and zero-downtime deployments
• Documented the deployment and rollback procedures

The Results

Tomas launched on schedule. Three months later, he has 40+ paying customers, zero security incidents, and an app that handles his current load with room to grow.

What This Cost

The full engagement — two weeks of our Full Transformation service — cost significantly less than the revenue Tomas would have lost from a security breach or prolonged downtime during his critical growth phase.

More importantly, Tomas now has a codebase he can confidently hand to a future CTO or development team. The AI-built foundation was solid. It just needed production engineering on top.

Key Takeaway

AI tools are remarkably good at building products. They're not built for making those products production-ready. That's not a failing — it's a different discipline. The gap between "it works" and "it works reliably, securely, and at scale" is where we operate.

If you recognize any of Tomas's warning signs in your own product, book a free Quick Audit. We'll tell you exactly where you stand and what needs fixing before you scale. No surprises, no sales pitch — just a clear, prioritized action plan.

Read more about the common issues we find in AI-built apps:

• 5 Things Bolt/Lovable Won't Fix
• Security Holes Every Vibe-Coded App Has
• MVP to Production: The Complete Checklist