Which parts of my AI-built app do I actually own?

The code, almost certainly. Every platform we tested puts your source code in a git host you control. The harder question is what else was created while you were building. A database, a payment account, and a domain all had to exist for your product to run, and any of them can be in someone else’s name.

Why “you own your code” is the easy question

Putting a repository in your GitHub account is straightforward, and all three platforms we tested do it. So the question most founders ask has a reassuring answer. It is also the one that decides the least.

Your code is a set of instructions. A running product is those instructions plus a database holding your customers, an account taking their money, and a domain they arrive at. Each of those is a separate commercial relationship, and each belongs to whoever the account was opened under.

The useful version of the question is whose name is on each of the things your product needs in order to run.

Four things that get owned separately

The code. The repository and its history. Nearly always yours. Worth confirming which git hosts a platform supports, and whether it builds from your repository or syncs to it afterwards, because those are different relationships with the same files.

The accounts. The database project, the payment account, the domain registration. Each is a commercial relationship with a provider, and it sits either with you or with the platform that opened it for you. Both are workable. Only one lets you reach your customers’ payment history after you stop paying for the platform.

The data, and separately its structure. These come apart more often than people expect. An export gives you rows. It does not always give you the schema, the constraints, and the migration history that make those rows mean something.

The keys. Whether you hold usable credentials to the services running your product, or only a console that displays them. An account in your name whose connection string you cannot obtain is an account you own on paper.

What each platform holds

Forged ran Emergent, Replit, and Lovable through the same test rounds. Everything below we observed first-hand, in the product, on our own accounts, in August and September 2026, except where a cell cites a vendor’s documentation.

What gets created	Lovable	Replit	Emergent
Source code	LovableYours, synced to GitHub or GitLab	ReplitYours, on GitHub, GitLab, or Bitbucket	EmergentYours, GitHub only
Database	LovableAuto-enabled in chat, on a Supabase project owned and managed by Lovable rather than your own Supabase account	ReplitProvisioned by default rather than opt-in	EmergentNo database service
Database credentials	LovableNo access to service role keys or direct database URLs, per Supabase’s documentation	ReplitThe connection string is yours, as a DATABASE_URL field with copy and reveal controls	EmergentNone created
Payment account	LovableStripe and Paddle switched on by default on an account that connected neither. Lovable provisions the Stripe account and you claim it at go-live, per Lovable’s documentation	ReplitNo payments service. Stripe appears as a sign-in integration for read access to your own account	EmergentProvisioned on Emergent’s own account, and you claim it at go-live

All three put your code in a git host you control, so the question everyone starts with has the same answer everywhere. They diverge on everything created alongside it. Lovable opens the payment account, the sign-in and the database on its own account, and only the payment account comes back, claimed at go-live, per Lovable’s documentation. The database stays with Lovable, and so does the sign-in, although the sign-in settings offer your own OAuth credentials as an alternative to the managed default. Replit provisions the database and hands you the connection string, but holds the app sign-in on its own account and never asks you for credentials. Emergent opens the payment account and the sign-in, and only the payment account comes back: it becomes yours at a claim step, while the sign-in has no such step and no alternative is offered.

The database is where this gets expensive. Lovable documents a way out and is explicit that it is manual: there is no one-click migration, so you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there yourself. So the data is yours to take and the structure is yours to rewrite. That is a smaller claim than “you cannot leave”, and it is far cheaper to act on while the schema is still small.

Domains belong on the same list, and all three sell them. A domain bought from any of them is a registrar relationship like any other.

How to find out what you hold

You do not need to leave a platform to learn what leaving would involve. Four checks, about ten minutes, on the product you have now.

Open the billing page of every service your product touches. The database, the payment processor, the domain registrar, the email sender. You are looking for one thing on each: whose name is on the account. If you cannot reach a billing page for something, somebody else is paying for it on your behalf.

Ask for the database connection string. Not a console, not an admin panel, the string itself. If you can get it, you hold the database. If there is no way to get one, you do not, whatever the ownership page says.

Run the export and open the file. Do it early, while nothing depends on the answer. You are checking whether the schema came with the rows, because that is the difference between a restore and a rebuild.

Check the domain. Who the registrar is, whose account it sits in, and whether you can move it.

How Forged handles this

Forged works differently because it builds inside a repository you already own.

The product is in your repository from the first change, rather than created inside a workspace and handed over later.

Dimension	The Forged approach
Source code	In your own repository, on the git host you connected
Existing integrations	Preserved, and connected directly by your application
Payments	Customer-owned Stripe
Managed Forged services	Provided where you choose them, such as Forged email services and Forged hosting
How a change arrives	As a pull request you review before it reaches your users

Customer-owned integrations do not become dependent on Forged. When your application connects directly to a service you own, such as Stripe or Auth0, Forged does not insert itself into that connection. Managed Forged services are different, because you have explicitly chosen Forged to provide that capability, and that choice is made one service at a time rather than as a bundle.

Payments stay yours. Stripe is normally a direct commercial relationship between you and the processor, and Forged treats it that way rather than sitting in the middle of the account your customers pay into.

And a change arrives where your code already lives. The output of a Forged build is a pull request in your own repository, so it is reviewed in the same place, by the same people, as any other change to your product.

Your questions, answered

Do I own the code an AI platform writes for me?

In our August 2026 rounds, all three platforms put source code in a git host you control. Confirm two things rather than assuming them: which git hosts are supported, since one of the three is GitHub only, and whether the platform builds from your repository or syncs to it afterwards.

Who owns the database Lovable creates?

Lovable. A Lovable Cloud instance is a Supabase project owned and managed by Lovable rather than by your own Supabase account, and Supabase’s documentation states that you get no access to service role keys or direct database URLs. Your data is exportable, and Lovable’s documentation is explicit that there is no one-click migration, so plan for the structure to be rebuilt rather than moved.

Who owns the Stripe account Lovable created?

You do, once you claim it. Lovable provisions the account, and its documentation describes claiming it at go-live through a link in the Payments tab. Worth doing early rather than at launch, since it is the account your revenue arrives in.

Does Replit give me my database connection string?

Yes. Replit provisions a database by default and exposes the connection string as a DATABASE_URL field with copy and reveal controls, described in the product as something to copy into any service that needs to connect.

Does Emergent create accounts in my name?

No. The payment account and the sign-in are both opened on Emergent’s own accounts. The payment account is one you claim as your own at go-live. The sign-in has no such step, and no alternative is offered. Emergent does not open storage or email at all, and asks instead which provider you use and for your credentials. There is no database service. Instead the agent writes MongoDB into your code. It also connects to GitHub only, where the other two support more than one git host.

See what you would own with Forged

Connect your repository and ask for one change. The result arrives as a pull request in the repository you already control.

Last reviewed: September 15, 2026.