Correction, October 13, 2026: Before Drafts, edits changed the main project; publishing was still a separate step. Drafts share the published database, so preview actions need separate care.
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, edits happened directly in the main project. Publishing those edits made them visible to users. 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 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. Design changes reach users only after you accept the draft and publish. Preview actions can still reach the published app’s database. 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. The feature works on projects with or without a database. Check your project dashboard for access before relying on Drafts in a workflow.
Drafts still use the live database
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 in the main 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.” Do not treat a design draft as a database sandbox. Check whether a preview action reaches the published app’s data before using it.
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. If an action in the preview writes to that published database, it can affect real data even before you publish the design changes. 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 handing off a draft, check which database its actions reach. Open More, then Cloud, in your project editor. If Lovable manages the database, open its Database view. If your project uses your Supabase account, follow the link to its dashboard and open Table Editor.
Test submissions in a separate, disposable project with test data. Disable external actions or use sandbox credentials for anything that sends emails, takes payments, or starts fulfillment. Fake signup or order details alone do not isolate those effects.
If you cannot isolate the write path and connected services, limit the draft review to layout and copy. Do not submit an order or signup against production just to see whether a row appears.
End of article