The Lovable to Next.js Conversion Prompt

Why convert a Lovable app to Next.js — and what actually changes

Lovable is excellent for going from idea to working app fast. But teams outgrow the default stack when they need server-side rendering for SEO, server-side data fetching, API routes co-located with the app, or simply a codebase that matches the rest of their Next.js infrastructure. That is when 'lovable to next.js conversion prompt' becomes a real search: people want a repeatable way to move the code across. Start by knowing your starting point. Apps created before mid-2026 are Vite single-page apps using React Router (BrowserRouter). Newer Lovable projects may already be on TanStack Start with SSR, which shortens the routing and data-fetching work. Either way, the backend is Supabase, and that part largely carries over unchanged — you keep the same database, auth, and storage, and only change how the frontend talks to them. The conversion itself is mechanical but detail-heavy: scaffold a Next.js App Router project, port components (they mostly move as-is because React, Tailwind, and shadcn/ui all work in Next), translate React Router routes into the app/ folder's file-based routing, rename environment variables from the VITE_ prefix to NEXT_PUBLIC_ (or drop the prefix for server-only secrets), and move any data fetching you want on the server into Server Components or Route Handlers. The prompt below drives an AI assistant through exactly these steps so you are reviewing diffs, not rewriting from scratch.

• SEO needs server-side rendering that a Vite SPA does not provide out of the box
• The team wants server-side data fetching, API routes, or Server Actions co-located with the app
• The codebase needs to match existing Next.js infrastructure and tooling
• React Router routes must be re-expressed as Next's file-based app/ routing
• Environment variables use the VITE_ prefix, which Next.js does not read

Error messages you might see

Before you start

• Your Lovable codebase exported (GitHub two-way sync, or Download codebase on a paid plan)
• Node.js 18+ locally and an AI coding assistant (Cursor, Claude, or Lovable's Code tab)
• Your Supabase project URL and keys (the backend does not change)
• A new empty git branch to convert into, so you can diff against the original

How to fix it

// Lovable: Vite entry
// src/main.tsx -> ReactDOM.createRoot + <BrowserRouter>

npx create-next-app@latest my-app --typescript --tailwind --app
# then copy src/components/** into the new project

<Route path="/orders/:id" element={<OrderDetail/>} />

// app/orders/[id]/page.tsx
export default function OrderDetail({ params }: { params: { id: string } }) { /* ... */ }

const url = import.meta.env.VITE_SUPABASE_URL;

const url = process.env.NEXT_PUBLIC_SUPABASE_URL!;

// Vite SPA: all data fetched in the browser via useEffect

// app/page.tsx (Server Component)
export default async function Page() {
  const supabase = createServerClient();
  const { data } = await supabase.from('orders').select('*');
  return <OrdersTable rows={data ?? []} />;
}

Complete code example

1# Paste-ready conversion prompt
2
3You are converting a Lovable app (Vite + React + TypeScript + Tailwind +
4shadcn/ui, React Router, Supabase backend) to Next.js (App Router).
5Work in small, reviewable steps and pause after each for my approval.
6
7## Do this in order
81. Inventory the project: list every React Router route (path -> component)
9   and every file that reads import.meta.env. Do not change code yet.
102. Scaffold routing: for each route, create app/<path>/page.tsx rendering the
11   same component. Convert dynamic params (:id) to [id]. Move providers and
12   shared layout into app/layout.tsx. Remove BrowserRouter/Routes/Route.
13   Replace react-router Link/useNavigate with next/link and next/navigation.
143. Environment: rename VITE_SUPABASE_URL -> NEXT_PUBLIC_SUPABASE_URL and
15   VITE_SUPABASE_PUBLISHABLE_KEY -> NEXT_PUBLIC_SUPABASE_ANON_KEY. Replace
16   every import.meta.env.X with process.env.X. Keep any service-role key
17   server-only (no NEXT_PUBLIC_ prefix).
184. Supabase clients: create a browser client for 'use client' components and
19   an SSR/server client (cookie-based) for Server Components and Route
20   Handlers. Do not change the database schema, auth, or storage.
215. Server vs client: mark interactive components 'use client'. Move data
22   fetching that should be server-rendered into async Server Components or
23   app/api Route Handlers. Wrap any window/document/localStorage access in a
24   client component or useEffect.
256. Build: run next build, fix every 'window is not defined' and missing-env
26   error, and report what changed.
27
28## Constraints
29- Do not change the Supabase database, RLS policies, or auth provider.
30- Keep all existing UI and shadcn/ui components; do not restyle.
31- After each step, list the files you created or modified.
32
33Start with step 1 and wait for my confirmation.

Best practices to prevent this

• Convert on a fresh branch so you can diff every change against the original Vite app
• Do it in steps (routing, env, clients, server/client split) and build after each — never in one giant prompt
• Keep the Supabase backend untouched; only change how the frontend connects to it
• Rename VITE_ vars to NEXT_PUBLIC_ for client use and keep secrets server-only with no public prefix
• Use the SSR-aware (cookie-based) Supabase auth pattern so Server Components can read the user
• Move only the data fetching that benefits from SSR to the server; leave interactive bits as client components
• Run next build early and often — most conversion bugs surface as 'window is not defined' or undefined env vars

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

Related error patterns