From Lovable
Move a Supabase-backed Lovable project to Layout. What transfers cleanly, what you re-describe, and the first prompt to send.
If you have a Lovable project you want to continue on Layout, a lot transfers cleanly — the stacks are close. This guide shows what to bring, what to re-describe, and how to make the first Layout build count.
What Layout and Lovable share
You will feel at home faster than you expect.
- Same frontend shape. React with a component-heavy structure. Lovable components usually drop into Layout with minimal adaptation.
- Same backend. Both use Supabase for auth, Postgres, and storage. Schema and auth concepts port directly.
- Same prompt-driven loop. Describe a change, review the build, iterate.
What is different
A few things to expect.
- Publishing. Layout publishes at
<subdomain>.layout-app.comout of the box. Pick a subdomain, click publish, done. - Versions. Every Layout build is a version you can preview, roll back to, or branch from. Use them liberally.
- Integration surface. Layout's Supabase connection is first-class — sign in once from the workspace, pick your project, and the app is wired.
Three ways to migrate
Pick the one that matches how much of the original project you want to keep.
Re-describe from a prompt
Write a prompt that captures the app, attach a screenshot of the current version, and let Layout generate from scratch. The fastest path and the one with the cleanest Layout-native output.
Best when the app is early or small.
Bring the Supabase project, rebuild the UI
Connect your existing Supabase project in Layout (see Editing your project). Your tables, users, and storage buckets stay where they are. Then describe the UI in prompts and let Layout build against the existing schema.
Best when the data is mature and the UI is the part you want to iterate on.
The migration prompt template
Whichever path you pick, the first Layout prompt should be specific. Use this shape.
Build {one-line description of the app}.
Audience: {who uses this}
Core flow: {what the main user does, step by step}
Data: {entities and fields — the schema in plain English}
Design: {tone, theme, any screenshots attached}
Out of scope: {what NOT to build yet}
Reference: I have a working version in Lovable — I attached a screenshot
of the main screen. Match the layout. Colors can change.Attach the screenshot of the main screen in the same prompt. Paste or drag it into the prompt box.
Bringing your Supabase project
If you want the same database, the cleanest path is to connect it to Layout before the first real build.
Create the Layout project
Start a new project from the home screen with a short description. Connect your Supabase project in the next step before your first build — this avoids writing any data to the wrong place.
Open the Supabase picker
Click the Supabase icon in the chat toolbar, just below the prompt input. Sign in to your Supabase account and pick the project Lovable has been using.
Review the migration plan
Layout shows the migrations it wants to apply to your Supabase project. Read them. Your existing tables stay; Layout only adds what the new app needs.
Confirm
Apply the migration. The app now reads and writes to your existing Supabase project, complete with your existing users and data.
What to expect, feature by feature
A sensible first day
Scope down
Pick the smallest version of the app that is still useful. Port that first. Everything else layers on once the core works.
Connect your Supabase project (optional)
If you plan to keep the existing database, connect it before the first meaningful build.
Write the migration prompt
Use the template above. Attach a screenshot of the main screen.
Review the first build
Open the preview. Check the layout, the main flow, and the data model. If something is off, describe the correction — do not rebuild the whole app in one follow-up.
Publish a staging version
Once the core works, pick a subdomain and publish. You now have a shareable URL and a checkpoint to return to.
Port feature by feature
Add the rest one prompt at a time. Attach screenshots from the old app when layout matters.
What not to do
- Do not paste the whole Lovable codebase in one prompt. Layout handles project structure on its own. Large code dumps confuse the AI more than they help.
- Do not re-create the Supabase schema by hand if you can connect the existing one. Fewer migrations means fewer chances for drift.
- Do not try to match pixel-for-pixel. Get close and move on. Fighting the design system for 1-pixel parity burns credits and time.