Lovable | Drafts Give Frontend Ideas a Separate Workspace
Lovable introduced drafts on September 7, 2026, giving frontend experiments a separate chat and preview. Designers and collaborators can explore different layouts or copy before accepting a direction, while the first release has an important boundary around database and login changes.
Explore a design direction without immediately replacing it
A draft is a copy of the project with its own working conversation and preview. Multiple drafts can be compared. Accepting one applies its changes to the project; publishing is the separate action that makes those changes live.
A landing page could have one draft for a simpler hero and another for a longer explanation. Compare both with the same images and text so the decision reflects the layout rather than unequal content. Name each experiment around the question it is trying to answer.
Collaboration works better with a defined review question
Instead of asking a collaborator to improve everything, give the draft a contained goal. A copy editor might refine labels and empty states, while a designer explores navigation or a new card arrangement.
Separate experiments are easier to assess when everyone knows what success looks like. For a signup page, that might mean a clearer explanation above the form and a consistent sequence of fields. Avoid combining an unrelated visual redesign with changes to how the application works.
The first release focuses on frontend changes
Drafts support layout, design, and copy work on projects with or without a database. Database-structure and login-setup changes remain in the main project conversation. Drafts currently use the published application's database.
That last detail deserves a practical check before testing a form or another data-writing action. A separate preview should not be treated as a separate data environment. Use controlled test records and understand the effects of a visitor action before sharing an experiment broadly.
Acceptance should follow a complete preview pass
Review the chosen direction with realistic content and the screen sizes the application needs to support. Check routes, buttons, forms, and loading states as well as the portion of the page that changed.
Keep a brief decision record explaining why one draft won. It helps the next collaborator understand which visual choices are intentional and reduces the chance that a later experiment reverses them without considering the original purpose.
IMPORTANT: Drafts use the published application's database. This release covers frontend changes; database structure and login setup still change through the main project chat.{alertWarning}
Daisuki's Take: What This Means for Web Designers
We see drafts as a useful space for evaluating alternatives in context. A working page can reveal problems that a written suggestion does not, especially when copy length and layout affect each other.
We would keep each draft focused and review it as a proposal. A separate preview creates room to experiment, but the team still needs to understand its connection to real application data.
The strongest workflow ends with a deliberate choice: compare, accept, verify, and publish. That keeps exploration useful without confusing the version under discussion with the version visitors actually use.
Sources and Recommended Links
- Introducing drafts: an easier way to collaborate and explore new ideas | Lovable Blog Official Site
