Lovable.dev to Next.js Conversion Prompt Guide

A Lovable.dev to Next.js conversion prompt should not ask an AI agent to rewrite the whole app in one pass. The reliable pattern is a short planning prompt followed by narrow slice prompts for auth, billing, one indexable route, and one dashboard route. Each slice needs a build command, a test command, a deployed preview, and a rollback lever.

The search results for this topic already include mega-prompts and converter tools. The problem with a mega-prompt is that it gives the model too much surface area at once. It will make plausible choices about Supabase sessions, Stripe webhooks, redirects, and metadata without knowing which choices your product depends on. Use the templates below as copy-ready starting points, but fill in real routes, tables, providers, and acceptance checks before running them.

Before you prompt: collect the facts

Paste only facts you are comfortable sharing with the AI tool you are using. Do not paste secret values. Use key names, route names, table names, and expected behavior instead.

• Current Lovable repo structure and package manager.
• List of public routes, protected routes, and dynamic routes.
• Supabase tables used by the app and whether RLS is enabled.
• Auth providers and callback URLs.
• Stripe, Mailgun, OpenAI, or other integrations by name only.
• Public URLs that already rank or receive traffic.
• Commands the repo must pass before a slice is accepted.

Planning prompt: turn the Lovable export into a migration map

You are migrating a Lovable-generated React app to Next.js App Router.
Goal:
Create a migration map only. Do not edit files yet.
Current app:

Framework: React + Vite from Lovable
Routing: [paste route list]
Data: Supabase tables [paste table names, not secrets]
Auth: [magic link, OAuth providers, roles]
Integrations: [Stripe, email, analytics, etc.]
Deployment target: [Vercel, Fly.io, or other]

Target app:

Next.js App Router
TypeScript
Tailwind/shadcn UI preserved where possible
Supabase SSR for cookie-based sessions
Server-rendered HTML for public SEO routes

Output:

Route mapping from React Router to App Router paths.
Components that can copy across unchanged.
Components that must stay client components.
Supabase calls that should move server-side.
Env vars that must become NEXT_PUBLIC_ vs server-only.
Integration callbacks that must be updated before launch.
A slice-by-slice migration order where each slice can compile, test, deploy, and roll back.

Constraints:

Do not expose service-role keys to the browser.
Do not change public URLs that already rank unless you also propose a 301 redirect.
Do not migrate dashboards before auth survives hard refresh on the deployed preview.

Slice prompt 1: Next.js shell and Supabase auth

Migrate only the application shell and authentication foundation.
Implement:

Next.js App Router layout.
Supabase SSR server and browser clients using @supabase/ssr.
Auth callback route.
Middleware or route guard for protected pages.
One stub protected page that confirms the user session survives hard refresh.

Do not implement:

Dashboards.
Billing.
Admin features.
Unrelated UI cleanup.

Acceptance checks:

bun run lint
bun run test
bun run build
Deployed preview supports sign-in, callback, hard refresh, and sign-out.
Missing or expired session redirects without a loop.

Rollback:

Keep the Lovable production app live.
Document the exact route or DNS change needed to send users back.

Slice prompt 2: billing and webhooks

Migrate only billing and webhook handling.
Implement:

Next.js route handler for Stripe webhooks.
Signature verification using the server-only webhook secret.
Idempotency storage or duplicate-event protection.
Structured logs for received, ignored, failed, and retried events.
A local replay fixture for at least one successful event and one duplicate event.

Do not implement:

New pricing UI.
New checkout flow unless it is required for the webhook test.

Acceptance checks:

Webhook route rejects unsigned requests.
Duplicate event does not double-write.
Tests cover success, bad signature, and duplicate event.
Secret names are documented, values are not.

Slice prompt 3: one indexable marketing route

Migrate one public marketing route that already matters for search.
Route:

Source Lovable route: [old route]
Target Next.js route: [new route]
Canonical URL: [final URL]

Implement:

App Router page.
Server-rendered body content.
Metadata API title and description.
Self-referencing canonical.
Open Graph tags.
JSON-LD if the page has visible FAQ, Article, Product, or Service content.
301 redirect if the URL changes.

Acceptance checks:

Googlebot user-agent fetch returns 200.
Initial HTML contains the H1 and main body text.
Exactly one canonical points to the final URL.
Sitemap includes the final URL.
Old URL redirects in one hop if changed.

Slice prompt 4: one dashboard route

Migrate one authenticated dashboard route.
Route:

Source Lovable route: [old route]
Target Next.js route: [new route]

Implement:

Server component for initial data fetch where appropriate.
Client component only for interactivity.
Supabase RLS-safe query using the signed-in user's session.
Empty, loading, and error states.

Acceptance checks:

Signed-out user cannot access the route.
Signed-in user sees only their own records.
Expired session does not show another user's data.
Hard refresh preserves the route state or redirects safely.
Tests cover the data boundary.

Do not ask AI to do this in one pass

A one-pass conversion prompt is tempting because it feels cheaper. It usually creates the expensive failure: a working-looking app with broken auth cookies, unsafe env vars, missing redirects, and metadata that does not match production. A slice prompt is slower in chat, but faster in real delivery because every slice ends in a verifiable checkpoint.

Acceptance criteria for every slice

• The slice has one route or one integration boundary.
• The code compiles and the agreed test command passes.
• The preview deployment exercises the real callback or route shape.
• The prompt names files the agent must not touch.
• The output includes a rollback note.
• SEO-sensitive pages are checked with a Googlebot user agent.

FAQ

What should a Lovable.dev to Next.js conversion prompt include?

It should include route inventory, data entities, auth flows, integrations, deployment target, SEO-critical URLs, acceptance commands, and rollback rules. It should also say what not to change. The strongest prompt is specific enough that the model does not invent your product architecture.

Can I automate the migration with a single mega-prompt?

You can use a single prompt for planning, but not for production migration. Use separate prompts for auth, billing, public SEO routes, and dashboards. Each prompt should end with a build, test, deployed preview, and rollback check.

How do I keep SEO parity during the move?

Preserve ranking URLs where possible. If a URL changes, use a single-hop 301. Match title, description, canonical, Open Graph tags, sitemap entry, and JSON-LD before cutover. Fetch the deployed page with a Googlebot user agent and confirm the body content is in the HTML.

What should I never paste into a conversion prompt?

Never paste secret values, service-role keys, webhook secrets, private tokens, or full magic-link URLs. Use secret names and describe behavior instead. The agent needs to know that STRIPE_WEBHOOK_SECRET exists, not what its value is.

Where to go next

Use the conversion playbook to decide whether the migration is worth doing and what order to run. Use the deeper senior engineer migration playbook when Supabase RLS, server components, or backend handoff is the real risk. For team coordination, see AppHandoff and Lovable agency services.