AI prototype to production — Lovable, Bolt, Cursor, in 2–6 weeks.

Anatomy of an AI MVP production-ready pass

Roughly 90% of vibe-coded projects never reach production. The ones that do tend to share the same shape on the day they become real: the builder preview works, the demo video is recorded, the waitlist is real, and then the first deploy to a custom domain breaks in one of five places — environment variables, Supabase RLS, OAuth redirects, Stripe webhooks, or SSL/canonical host routing. The productionization pass exists to clear those five in a defined order before launch day turns into an incident post-mortem.

Week zero is the 48-hour audit. Two senior engineers read the repo, run the current deploy, and reproduce every known bug the founder documented. We map every environment variable between the preview and the production host, enumerate every Supabase table for RLS posture, test every OAuth redirect URI, verify every Stripe webhook, and confirm SSL + canonical host routing on the production domain. The output is a written productionization plan: phased checklist, fixed fee, fixed window, with every known blocker either scheduled or explicitly out of scope.

Week one is auth, data, and payments. These three surfaces share a property: when any of them is broken in production, the user experience is effectively zero. A user who cannot log in is a user who has already churned. Supabase RLS goes on every table that reads or writes tenant data. Stripe webhook handlers get signature verification and idempotency keyed on event.id. Session cookies get their domain, SameSite, and Secure attributes set correctly for the production host. Every change lands as its own commit, tagged and reviewable, so the founder sees progress daily.

Weeks two and three are infrastructure. A CI/CD pipeline on Vercel or Netlify running type-check, ESLint, and Playwright smoke tests on every PR before merge. A staging environment on a non-production database so deploys can be rehearsed. Preview URLs on every PR so reviewers can click before code lands. A documented rollback path — the Vercel dashboard or a single CLI command — that a founder who has never rolled a deploy back can execute on a Saturday night. Monitoring via Sentry for errors, uptime checks for the home route and the critical auth + purchase paths, and a Slack channel that gets paged the moment any of them breach threshold.

Weeks three to five are tests, documentation, and launch. We write Playwright smoke tests for the three critical paths — sign-up, sign-in, and the primary money path (checkout, subscription start, or whatever the product does). We add integration tests on the Stripe webhook handler and the Supabase RLS policies. We write an architecture overview — folder conventions, data flow, deploy checklist, rollback runbook, incident playbook. We write a project rules file so the next time the founder prompts Cursor or Claude Code, the AI sees the conventions first and stays on-architecture. Launch day runs through the written checklist with rollback kept warm.

Week six is post-launch on-call. Seven days of active monitoring. Any Sentry spike, any uptime alert, any customer report gets triaged within two business hours. Most weeks nothing dramatic happens; occasionally we catch a regression in a third-party dependency, an edge-case RLS policy, or a Stripe webhook retry that surfaces a race condition. If you want ongoing coverage after the seven days, the Retainer engagement picks up where on-call ends.

What the productionization will not do. We will not redesign the product. We will not pick a different framework unless the current one is genuinely broken for production. We will not run a full security pen-test — use the $499 Security Audit first if that is the primary concern. We will not rewrite AI-generated code the founder is still actively adding to; freeze AI commits during the engagement or book AI-generated code cleanup before production hardening begins. The productionization pass is one discipline: move an AI-built prototype from working-for-the-demo to surviving-real-users in a fixed window.