From Vibe-Coded Prototype to Production: The Hardening Playbook

A prototype built by prompting Lovable, Bolt, Base44, Replit or a coding agent can look finished long before it is safe to run with real users and real data. The gap is rarely visible in the interface. It sits in access rules, secrets, error handling and the absence of tests. This playbook describes the hardening work in the order we recommend doing it, with a triage table to decide what blocks launch and what can follow.

Phase 0: Freeze and inventory (day 1–2)

Stop adding features. Hardening a moving target does not work. Then build an inventory:

• Where is the code? Make sure it is in a Git repository you control, not only inside the builder.
• Which services are involved: hosting, database, auth, storage, payment, email, AI model APIs, analytics?
• Which environment variables and keys exist, and where are they stored?
• Which user roles exist, and what should each be allowed to see and change?
• Which flows make money or handle personal data? Those get the most attention.

Phase 1: Security fundamentals

These are the problems we find most often in AI-generated apps, and the fix for each:

1. Secrets in the frontend. API keys for model providers, payment or email services bundled into client code can be read by anyone. Move calls that need secret keys to server-side functions. Public keys designed for the client (for example a Supabase anon key) are fine only if access rules are correct.
2. Missing or permissive access rules. With Supabase, every table exposed to the client needs Row Level Security enabled and policies that restrict rows to the right user or organization. Test by querying as a second user.
3. Authorization only in the UI. Hiding a button is not access control. Every server function must check who is calling and whether they may perform the action.
4. Unvalidated input. Validate types, lengths and formats on the server, including file uploads.
5. Prompt injection paths. If user content is sent to an LLM that can call tools or see other users' data, restrict the tools and data it can reach.
6. Dependency hygiene. Run an audit of packages, remove unused ones and update anything with known critical vulnerabilities.

The broader threat model is covered in security risks of agentic coding.

Phase 2: Data model, privacy and backups

• Review the schema for duplicated or ambiguous tables that the generator created across iterations; consolidate before data accumulates.
• Add database migrations to the repository so schema changes are versioned.
• Enable automated backups and do one test restore. A backup you have never restored is a hope, not a backup.
• List which personal data you store, why, and for how long. Add account deletion if users can create accounts, which Apple also requires for apps in the App Store.
• Check where model providers process data and whether you need a data processing agreement.

Phase 3: Tests around what matters

You do not need full coverage before launch. You need a safety net around the flows that would hurt most if they broke:

• End-to-end tests for sign-up, login, the core user action and payment.
• Tests for access rules: user A must not be able to read or change user B's data.
• Unit tests for calculations, pricing logic and data transformations.
• A small evaluation set for any AI feature, rerun when prompts or models change.

Details on approach and tooling are in testing strategies for AI-generated code.

Phase 4: Observability and deployment

• Error tracking in frontend and backend, with alerts to a channel someone watches.
• Uptime checks on the main pages and API endpoints.
• Usage and cost monitoring for model APIs, with spending limits set at the provider.
• Separate staging and production environments with separate databases and keys.
• A deployment path that runs tests automatically and can be rolled back. For Lovable-specific hosting choices, see deploying a Lovable app to production.

Also check performance basics before launch: queries without indexes on large tables, components that fetch the same data repeatedly, unoptimized images and AI calls made on every keystroke instead of on submit. Generated code often works fine with ten test records and slows down noticeably with ten thousand, so seed staging with realistic volumes and measure page load and API response times there.

Triage: what blocks launch

Phase 5: Ownership and handover

Production means someone is responsible at 2 a.m. Document the architecture on one page, list every external service with its account owner, write a short runbook for the three most likely incidents and decide who maintains the app. If the code has grown beyond what the builder handles comfortably, the next step may be a structured rescue; see rescuing AI-generated code.

If you want experienced engineers to run this playbook with you, OnlineAppCreator takes on production hardening for AI-built apps, and UXreviewer.io can review the user experience in parallel so launch fixes cover both code and usability.