Lovable Raises $400M—Exportable Code Does Not Remove Every Lock-In

Lovable’s August 13 Series C announcement says the company raised $400 million at a $13.3 billion valuation, with Menlo Ventures leading and the EQT-managed Scaleup Europe Fund co-leading.

An August 12 Axios deal item independently listed the completed $400 million round and $13.3 billion post-money valuation. For founders building businesses on Lovable, the financing puts a sharper focus on what they actually control: source code is portable, but the surrounding data and administrative state do not automatically move with it.

The valuation does not redefine ownership

The financing establishes what investors were willing to pay for a stake in Lovable; it does not broaden the assets included when a founder exports a project. Code ownership and operational independence remain different questions.

A generated application can span several layers. Its repository contains source files and change history, while its database holds live business records. Secrets, deployment configuration, workspace roles and login access may sit elsewhere again. Owning or exporting one layer does not produce a complete, restorable copy of the operating service.

This distinction becomes more important when a project moves beyond a prototype. A founder may possess every source file and still depend on platform-specific permissions, an external database account or another person’s repository organization to maintain the application.

Exportable code has a defined boundary

Lovable’s current ownership and account FAQ states that creators own their projects and code, can download a codebase as a ZIP or transfer it to GitHub or GitLab, cannot start a Lovable project by importing an existing external codebase, receive only a code restoration when reverting a version, cannot directly change a login email, and may transfer project ownership only to a full member of the same workspace.

The export options give founders meaningful custody of the software itself. A repository controlled through a company GitHub organization can preserve source history outside Lovable and provide a path for local development or deployment through other services.

That portability is directional rather than fully symmetrical. Code can move from Lovable into an external repository, but an existing repository cannot simply be imported to recreate the same Lovable project. The repository is therefore an exit path for continued software development, not a complete backup of the platform environment.

A code rollback is not a database rollback

The most consequential continuity boundary concerns live data. Restoring an earlier project version returns the code to that point, but records added or deleted afterward remain in the database. The result can be older application logic operating against newer data.

Whether that mismatch causes a failure depends on what changed. A visual revision may have little effect, while a change to fields, authentication logic or record relationships can leave the restored code expecting a different database structure or state.

Repository history cannot resolve that problem by itself. Code recovery requires a usable source copy; data recovery requires database backups, access credentials and a tested restoration path appropriate to the selected backend. These are separate continuity controls even when the application was originally generated as one project.

Project ownership and account access remain separate

Transferring a Lovable project is not the same as transferring its external repository, database or personal login. The intended recipient must qualify as a full workspace member before receiving project ownership; collaborator access or a pending invitation is insufficient.

The login-email restriction creates another administrative dependency. Moving to a new identity requires a new account and a project-moving workflow rather than a direct email change. That process should not be assumed to reproduce every part of a running project merely because the code remains available.

Repository custody can also sit with a different person or organization from the Lovable project owner. If a founder leaves a company-controlled project connected to a personal GitHub account—or the reverse—a later handoff can preserve access on one side while breaking it on the other.

The continuity checklist after the Series C

The practical ownership test is whether the business controls each operational layer independently enough to recover or transfer it. A founder-focused exit review should establish:

• Repository custody: which person or organization owns the external repository, who has administrator access and whether the company can continue development without the original Lovable account.
• Database state: where production records live, who controls the database credentials and whether a usable backup-and-restore process exists separately from code version history.
• Project administration: who owns the Lovable project and workspace, and whether an intended successor is already eligible to receive ownership.
• Account recovery: which login and recovery methods control the relevant accounts, particularly where a direct email change is unavailable.

Lovable’s Series C is complete, and its code-export options provide founders with substantial control over generated software. The remaining lock-in lies in the parts that code export does not reproduce: live database state, platform history, workspace permissions and account identity. What remains unknown is whether Lovable will expand its import, transfer and recovery capabilities as the platform grows after the round.

Also read:

• “Open Weight” Does Not Mean Safe for Commercial Use—Check the License Chain
• Custom Web Apps Fit the Workflow—but Ownership Does Not End at Launch
• Kling AI Raises $2.8 Billion at $18 Billion Valuation in July 2026 Round