What changed

Lovable introduced Drafts, a way to test changes to a project without touching the version your users see. Lovable is an AI app builder: you describe what you want in plain English inside a chat, and it writes and runs the code for you, no separate coding tool required.

Before Drafts, every edit landed straight in your live project. Change your mind, and you had to hit revert. Work with a teammate or client, and one of you had to wait for the other to finish, or copy the whole project to make separate changes, an awkward way to combine everyone’s work afterward.

A Draft is a full copy of your project with its own chat and its own preview. You or a collaborator can try out a new layout, a different color scheme, or new copy inside a draft while the live app keeps running exactly as it is. Nothing changes for your users until you open the draft, hit accept, and then hit publish. You can also run several drafts side by side, each testing a different direction, and only carry forward the one that works.

Lovable announced Drafts on September 7, 2026, and says the feature works on any project, whether or not that project has a database attached. The announcement does not say whether Drafts requires a specific paid plan, so check your own project’s dashboard to confirm you have access rather than assuming it.

The part worth reading twice

Drafts only cover what a visitor sees and clicks: layout, design, copy, colors, fonts, animations, and images. Anything touching your database’s structure or your login setup still happens directly in your live project’s chat, not inside a draft.

That split creates a detail easy to miss. Lovable’s own post says drafts “work against your published application’s database.” In plain terms, a draft doesn’t get a copy of your data to play with. It reads and writes the same live database your real app uses.

That matters if your draft includes anything that touches data while you’re testing it, a signup form, a checkout flow, a comment box, a button that saves a record. Even though the visual changes in that draft are never published, actions that write data inside the draft’s preview can still land in your real, live database. The draft protects your published code from unwanted changes. It does not put a wall around your data.

Who should care

This affects builders who use Lovable to run internal tools, sell products, or serve real signups, anyone whose app already stores real user or business data. If you’re building a portfolio site or a static landing page, this is largely academic since there is little live data to affect.

It matters most when a collaborator, like a teammate, a client, or a freelance copywriter, is the one poking around inside a draft. Someone testing “what does this checkout page look like with different copy” might click through the whole flow, including the part that submits an order, without realizing that click just placed a real order in the live database.

What builders should do next

Before you hand a draft to anyone else, or use one yourself to test a page with a form or a button that saves something, check what that interaction actually does with your data. In your project editor, open More, then Cloud, to see where your stored records live. If Lovable is managing your database for you, that panel has its own Database view, a simple table of your stored rows. If your project instead runs on your own account with Supabase, a separate database service some Lovable projects connect to, that same panel links out to Supabase’s dashboard, where its Table Editor shows the same kind of row-by-row view. Either way, click through the form or action inside a draft’s preview, then check that view for a new record. If a fake test signup or order shows up, you now know that flow writes for real, draft or not.

For pages where that risk applies, either use fake test data you’re comfortable adding to your live database, or hold off on drafting flows that write data until you can test them in a project you’re fine treating as disposable. Save Drafts for what they’re built for: layout, copy, and visual changes you want to compare before committing, not for a safe rehearsal of anything that touches a database.

End of article