The Wall
You shipped a prototype with Lovable, Bolt, or Cursor. It demos beautifully. You sent it to ten users. Two complained about something obvious. You shipped a fix. Now five things you thought were working don't.
This is the production wall. Every vibecoded app hits it. The 20% of work that vibecoders skip is the 80% that decides whether the product survives.
Here's the 4-week playbook we run on graduation engagements.
Week 1: Audit and Stabilization
Day 1-2: Code audit
- Pull the entire codebase into your repo (not the vibecoding tool's hosted version)
- Run linters, security scanners, dependency audits
- Identify hardcoded secrets, API keys in client bundles, exposed credentials
- Document the data model (whatever exists)
- Document the auth model (whatever exists)
Day 3-4: Critical security pass
- Rotate every API key
- Move every secret to server-side environment variables
- Add basic rate limiting on every endpoint
- Patch the worst vulnerabilities (SQL injection, XSS, exposed admin endpoints)
Day 5-7: Stabilization sprint
- Pick the top 5 user-reported bugs and fix them deterministically
- Add basic monitoring (Sentry, Logflare, or equivalent)
- Set up a staging environment that mirrors production
- Snapshot the database; document the rollback procedure
End of week 1: the bleeding is stopped. You are no longer one bug away from a public incident.
Week 2: Architecture Hardening
Day 8-10: Replace what's fragile
- Migrate from SQLite/Replit DB to managed Postgres (Supabase, Neon, or RDS)
- Move file storage from local disk to S3 / Cloudflare R2 / Supabase Storage
- Replace any in-memory state with persistent storage
- Add background job queue for any operation > 5 seconds
Day 11-12: AI architecture
- Wrap every model call in a thin routing layer (LiteLLM)
- Move provider keys to server-side env vars
- Add fallback providers for critical paths
- Log every prompt + response to a database table for audit
Day 13-14: Test coverage where it matters
- Tests for auth flows (signup, login, password reset)
- Tests for payment flows (Stripe webhook idempotency is non-negotiable)
- Tests for the critical user journey end-to-end (Playwright or Cypress)
End of week 2: the architecture is no longer hostile to its own future.
Week 3: Evals and Observability
Day 15-17: Write the eval suite
- For each AI call type, define inputs, expected behaviors, quality thresholds
- Generate at least 25 representative test cases per call type
- Wire evals to run in CI on every PR
- Configure CI to fail the build when thresholds drop
Day 18-19: Observability
- Latency tracking per endpoint (p50, p95, p99)
- Cost tracking per AI call type
- Cost-per-customer dashboard
- Cost-per-feature dashboard
- Error rate alerts to Slack/Discord
Day 20-21: Cost optimization pass
- Identify the top 3 most expensive call types
- Route non-critical calls to cheaper models
- Cache results where possible
- Add user-facing cost transparency where appropriate
End of week 3: you can see what's happening. You can prove what's improving.
Week 4: Launch Readiness
Day 22-24: UX polish
- Design proper loading states (not blank screens)
- Design proper error states (not raw stack traces)
- Add streaming where it improves perceived latency
- Add user feedback affordances on every AI output
Day 25-26: Documentation
- Write the runbook (common incidents, how to respond)
- Document the architecture (diagram + plain English description)
- Document the eval criteria
- Set up the user-facing changelog
Day 27-28: Soft re-launch
- Re-onboard the original test users with the production-grade version
- Solicit specific feedback (the 5-question post-use survey)
- Monitor closely for 72 hours
End of week 4: the product is production-ready. You can run it without a developer touching it daily.
What Comes After
After graduation, the right shape is an AI Operations retainer. Monthly. Eval monitoring, model updates, prompt tuning, monthly feature releases, cost engineering. We do this for our own products. We do it for clients.
The Honest Read
A 4-week graduation engagement does not turn every prototype into a production app. Some prototypes are too far gone. Fundamental architectural decisions baked into the code can block any reasonable production path. We tell buyers that on the discovery call.
But most prototypes can be graduated. The pattern is consistent. The work is repeatable. We scope it per engagement and quote it after a discovery call.
If you've hit the production wall on a Lovable, Bolt, or Cursor build and want a structured plan to ship it, that's exactly what the Kastling Project engagement is.