Migrate AI prototype to production.

What actually moves and what doesn’t

The decision tree on every migration is the same: the UI ports cleanly (Tailwind classes, React components, shadcn primitives), the data layer ports with care (Supabase schemas, RLS policies, storage buckets), and the integration code almost always needs a rewrite. AI builders generate webhook handlers, OAuth wiring, and Stripe integrations that look right but skip signature verification, raw-body parsing, idempotency, and error handling. We rebuild those four specifically — see Stripe webhook not firing and OAuth callback URL not working in production for the exact failure modes.

The target stack

For most prototypes we land on Next.js App Router, Supabase for auth + data, Stripe for payments, and Vercel for hosting. This isn’t dogma; it’s what inherits the AI-generated code cleanly and keeps the bill predictable. If you need a different runtime (Fly.io for long-running workers, Cloudflare for edge, a self-hosted Postgres for compliance) we route there instead.

How SEO and sessions survive the cutover

Same URLs where possible, 301 redirects where not, sitemap resubmitted to Search Console the day of cutover, canonicals audited before the DNS flip. Authenticated sessions survive because we port the Supabase user table by uuidand keep the JWT secret; users stay logged in through the migration. Stripe customer IDs port over so active subscriptions don’t get lost. The old system stays up for a week as a warm fallback.

What you get

A fixed-price scope after the 48-hour audit. A written cutover runbook with rollback steps. A Next.js repo you own, deployed to your own Vercel org. See the pricing page for tier breakdowns or the full App Migration service for the end-to-end scope.