Lovable

What Lovable is and produces

Lovable is a platform for developing web applications through natural-language instructions. Its output can include an interface, server logic, database, authentication and integrations, with editable code. A project represents one application; a workspace brings together people, projects and shared resources.

The useful unit of work is behavior that can be tested: finding a resource, saving a booking or displaying authorized information. An attractive screen is only part of the result. To assess an application, follow information from input to storage and check what happens when a value is missing, a permission changes or a service fails.

Reference documentation: Welcome to Lovable.

Origins and product evolution

The precursor is GPT Engineer, an open-source project Anton Osika published in spring 2023. Osika and Fabian Hedin subsequently developed Lovable, which the company dates as launching under that brand in November 2024. Both founders received the 2025 KTH Innovation Award.

This evolution explains its focus: moving from generating files to supporting application construction and operation. The original open-source project, the commercial service and the code of a customer-built application are different things; the first does not make the entire current platform open-source software.

Reference documentation: Engineering history · Series C announcement · KTH Innovation Award.

Company and financing

Company announcements document three significant rounds: on 17 July 2025, $200 million at a $1.8 billion valuation, led by Accel; on 18 December 2025, $330 million at a $6.6 billion valuation, with CapitalG and Menlo Ventures; and on 12 August 2026, $400 million at a $13.3 billion valuation, led by Menlo Ventures and the Scaleup Europe Fund.

These figures describe private financing at specific dates. They help explain company and infrastructure expansion, but are not revenue, profit or a publicly available price for buying its shares.

Reference documentation: Series A announcement · Series B announcement · Series C announcement.

Technology and application structure

Lovable describes technical evolution involving persistent execution environments and retrieval of instructions relevant to the agent. It is not simply one conversational model. New projects have used TanStack Start since 13 May 2026, or 22 June for Enterprise. Older projects may use React and Vite and have an upgrade path.

TanStack Start renders pages on the server. This matters when checking the HTML received by visitors or crawlers and when choosing external hosting. A migration should verify routes, authentication and metadata. The prepared project change is not served publicly until the application is published again.

Reference documentation: Engineering history · TanStack Start upgrade.

Chat, planning and building

Chat supports discussion; Plan investigates and presents an editable proposal without changing code; Build, formerly Agent, implements changes and displays their differences. Persistent workspace and project instructions, formerly Knowledge, provide context. Skills load when relevant.

A useful specification defines users, permitted information, states, errors and acceptance criteria. For a multilingual catalogue, for example, decide whether languages share an identifier, what happens when a translation is missing and who may withdraw an entry. These decisions should precede visual instructions about colors or layout.

Reference documentation: Build mode · Plan mode · Instructions.

Visual editing and precise changes

The preview toolbar replaces the earlier Visual edits experience. It supports selecting elements, editing text inline, drawing annotations and adding comments. Selecting a card provides context to the agent; a comment supports review without describing its location in another conversation.

To preserve consistency, request a small correction and check several screens: a translated heading may occupy two lines, a button may lose its label or a component change may appear across the site. Reviewing with a keyboard, enlarged text and long content gives more useful evidence than approving a screenshot alone.

Reference documentation: Preview toolbar.

Data, authentication and agent permissions

The built-in backend, also called Cloud, uses Supabase’s open-source foundation and includes a database, storage, authentication and functions. Agent permissions distinguish reading, changing data and modifying structure. In the documentation reviewed, incompatible migrations are blocked by default while other operations are allowed.

Separate three questions: who can change the code, who can enter the application and which records each person can access. Having an account does not grant access to every row. Likewise, changing development copy and changing a stored record are different actions: editorial review of a site does not replace control of its data.

Reference documentation: Built-in backend.

Behavior and security testing

Browser tests run against the preview in a remote environment. They can exercise forms and screen sizes, but have limitations with canvases, dragging and visual details; external authentication also limits coverage. Quick scan checks specific controls when publishing; Deep scan analyzes code for logic, authorization and exposure problems.

An effective test states both an expected and a forbidden result. For example, a reader can open a published entry but must not retrieve it through its URL after withdrawal if the content is meant to become unavailable. Test both cases and record the version, account and data used. A scanner and a functional test answer different questions.

Reference documentation: Browser testing · Security overview.

Publishing and visible versions

Publishing deploys a snapshot to a URL; later changes require republishing. Editor permissions and public-site access are independent.

For a resource library, verify from the public address using a session equivalent to the intended reader’s. Open deep links, reload an internal page and check that the selected language remains correct. Deployment confirmation establishes a technical operation; content review establishes what the audience receives.

Reference documentation: Publish your Lovable project.

Ownership, Git and leaving the platform

Lovable documents ownership of created code and content, subject to third-party rights. Git synchronization keeps a code copy and supports developer collaboration; GitHub is not required to use the service. Moving a complete application requires separate consideration of its interface, data, authentication, storage and integrations.

A portability exercise starts a copy, imports fictional data and checks access to files and services. Exporting a repository alone should not be described as preserving the whole system. The dependency inventory should also cover credentials, domain configuration and scheduled jobs, with owners responsible for maintaining them.

Reference documentation: Sync project with GitHub · Ownership and portability.

Web, desktop and mobile

Alongside the browser, Lovable provides desktop applications for macOS and Windows and mobile apps for iOS and Android. Desktop adds connectivity with local MCP servers. Mobile lets users continue projects with the same account and credits.

These applications are authoring surfaces. A built project publishes to the web: Lovable does not generate React Native or provide direct app-store submission. A PWA or an external wrapper is a different option requiring additional work. For prevention resources accessed on phones, check connectivity, touch target size, document downloading and recovery after a session is lost.

Reference documentation: Desktop app · Mobile app · Publish your Lovable project.

Plans, usage and data handling

The plans are Free, Pro, Business and Enterprise. One credit balance covers building, chat, hosting, backend and application AI. The cost of operating a website therefore depends on usage as well as instructions sent to create it.

Since 9 September 2026, Free and Pro content may contribute to training, with individual prospective opt-out. Business and Enterprise are excluded by default. The documentation distinguishes this content from data submitted by applications’ end users, which is not used for training.

When budgeting, separate three scenarios of your own: preparation, ordinary traffic and a campaign with additional visitors. This identifies who monitors usage and which limits should apply before the address is widely shared.

Reference documentation: Subscription plans · Credits and usage · Data training controls.

Documented incidents and lessons

The CVE-2025-48757 record describes insufficient RLS policies in generated sites through 15 April 2025. It includes the vendor’s dispute, pointing to customers’ responsibility for their application data. It does not establish that all current applications have the flaw.

Separately, Lovable acknowledged a regression allowing access to public-project code and conversations between 3 February and 20 April 2026. It reported a fix and excluded private projects and Cloud from the scope. The incident reinforces the distinction between editor visibility and application access.

Reference documentation: CVE-2025-48757 record · April 2026 incident response.

Practical applications in OSH

It can help explore ways to present safety resources, organize materials or simplify an internal information request. Its occupational safety role supports design and development: ideas can be tested quickly, but content, permissions and operating criteria must be defined and reviewed independently of assumptions made by the generator.

Other proposed uses include a welcome page explaining where resources are located and a demonstration of site-specific material lookup. Separate public and internal content during design. An internal label or hidden button does not enforce permissions: someone requesting a resource must also be authorised when accessing its address directly.

Worked example and result checks

For example, a prototype portal could group approved materials by language and topic using public links. The team would assess search and readability before deciding whether the idea should become an actively maintained tool for employees.

For the example portal, define each resource by title, language, topic, review date and authorised link. Prepare a small dataset with controlled duplicates and a withdrawn document to check how those states appear. Specify a clear rule: search offers current materials and explains when a version is no longer available.

Test searches in all three languages and verify that filtering does not inadvertently change the document’s language. Correct a title and check both list and detail views. If accounts are introduced, use two fictional identities with different permissions and verify actual data access, rather than only visible buttons. Final review should identify the tested version and intended audience before publishing. Retain a brief record of expected outcomes so later changes can be checked against the same editorial requirements.

Limitations and conditions of use

A polished interface can conceal access, validation or storage problems. Review code and configuration, use fictional data during testing and avoid publishing a project containing real information before checking its controls and assigning responsibility for its operation.

Lovable’s security guidance explains that browser code can be inspected or changed and must not decide sensitive access. Authorisation needs verification on the server and through the appropriate data-access rules. A clean scan does not establish correct application logic: it may not detect a withdrawn guide being offered or an approval that never occurred. Review these editorial rules as well as technical findings.

Reference documentation: Publish your Lovable project · Security best practices for Lovable apps.

When to choose it and how to complement it

Lovable fits testing a web experience and evolving it with reviewable code. Figma may resolve early structural questions without connecting real data. Replit offers another development environment to compare when the team needs closer inspection of execution and changes.

Assess portability, access control, maintenance and ease of correcting rules alongside the initial appearance. Include an unauthorised request and a missing resource in the trial; a blank screen or technical error does not explain how users should proceed. Determine who maintains the resource catalogue after the development project ends.

Frequently asked questions

Are sharing the project and publishing the app the same?

No. Project collaboration and access to the published application have different purposes and controls. Review both before adding external collaborators or readers.

Does hiding a button protect an operation?

No. Permissions must be checked where the operation executes and data is accessed. The interface can only help present available actions.

Does GitHub sync create a complete service backup?

It retains code, but the service may also depend on data, secrets and hosting configuration. Document those dependencies and test recovery before considering continuity resolved.