How to Own Your App's Source Code When an AI Builder Made It

To own your app's source code, you need three things in your name: the code itself in a repository you control, the accounts it depends on, and a written record that you paid for the work and it belongs to you. Most people building with an AI tool skip all three until something goes wrong. Here is how to get all three, in order, before that happens.

Why this matters more with an AI builder

When a friend's cousin builds you a website, you at least know where the files live. Somebody's laptop, probably.

With an AI builder, the code lives inside a platform. You typed sentences, the tool wrote software, and it all sits on servers you never touched. That is normal and fine. It is also easy to leave that way, which is not fine.

If you never move the code out to something you control, you do not own an app. You own a login. If that login stops working, or the company changes its terms, or you just want to switch tools someday, you have nothing to hold.

Owning your app's source code is not about distrust. It is about being able to walk away from any single vendor, including the good ones, and still have your business.

Step 1: Ask for a repository, not a zip file

The first step is knowing what "the code" should look like. It is not one big file. It is a folder structure, usually managed by a tool called Git, usually hosted somewhere like GitHub or GitLab.

Ask whoever built your app: "Can you give me access to the Git repository?" Not a download link. Not a zip file emailed to you. A repository, with history.

Why history matters: it shows every change, in order, with a date. If a bug shows up later, someone can look back and see exactly what changed and when. A zip file is a snapshot with no past. A repository is a record.

Step 2: Create the account yourself, in your name

Here is the step people skip. They let the builder create the GitHub account, "for now." The account sits under the builder's email, the builder's company, the builder's control.

Do it the other way. Before any code exists, or as early as possible:

• Create your own GitHub (or GitLab) account, with an email address you own, like one at your company's domain.
• Give the builder access to that repository as a collaborator, not the other way around.
• Confirm you are listed as the owner of the repository, not just a member.

This one step, done early, prevents almost every ownership dispute I have seen. It costs nothing and takes ten minutes.

Step 3: Get the deployment accounts in your name too

Code is only half of it. Your app also lives somewhere it runs — a hosting service, a database, an email-sending service, a payment processor. Each of these is a separate account, and each one needs to be in your name for the same reason as the repository.

Make a simple list. For each service your app depends on, write down:

• The name of the service (hosting, database, domain registrar, email, payments, analytics)
• Who currently owns the account
• The login email on file

Then, one by one, either create the account yourself and hand access to your builder, or ask the builder to transfer ownership to your email address. Most services have a formal "transfer ownership" option in settings. Use it. Do not just get added as a second admin while someone else stays the primary owner.

Step 4: Get the environment variables and keys

Every app has a set of secret settings behind the scenes — API keys, database passwords, tokens for services like payment processing or email. These are usually stored in something called environment variables.

Ask your builder for a full, current export of these values, stored somewhere safe like a password manager you control, not a shared document that expires or a chat message that scrolls away.

This step matters because even if you own the code and the accounts, without these keys the app will not actually run. It is like owning a car with no keys cut for you.

Step 5: Put ownership in writing, before the build starts

If you are paying someone to build software for you — human, AI-assisted, or both — get a short written agreement that says, plainly:

• You own the code once it is paid for, in full
• The code will be delivered in a repository you control
• Any accounts created during the build will be transferred to you or created under your name from the start
• There is no license fee or ongoing payment required to keep using or modifying the code

This does not need to be long. A few sentences in an email, agreed to before work starts, is enough to avoid a bad conversation later. Get it before the first line of code, not after the last invoice.

Step 6: Verify you can actually rebuild and redeploy, without the builder

Ownership on paper is different from ownership in practice. The real test: could you, or someone new you hire, take the repository, follow a setup guide, and get the app running again from nothing?

Ask your builder for a short setup document — what to install, what commands to run, where the keys go. Then, ideally, have someone who was not involved in the build try to follow it. If they can get the app running, you have real ownership. If they get stuck immediately, you have a repository, but you do not yet have independence.

This is close to what a good verifier does at a studio like Australis: someone who was not part of building the app opens it fresh and checks that it actually works the way a real user would experience it — which naturally exposes whether the handoff is complete, not just whether the code exists somewhere.

Step 7: Set a calendar reminder to check again in six months

Ownership is not a one-time task. Accounts get recreated during fixes. New services get added when the app grows. A new API key gets generated and lives only in someone's terminal history.

Every six months, run through your list from Step 3 again. Confirm you are still the owner of everything. Confirm you still have the current keys. This ten-minute check now saves a frantic scramble later, usually at the worst possible time — right when you need to switch vendors or fix something urgent.

The takeaway

Owning your app's source code is not a legal formality you handle once and forget. It is a short, repeatable checklist: your own repository, your own accounts, your keys in your hands, a plain written agreement, and a working test that someone new could pick it up. Do these seven steps once, properly, at the start of any build, and you will never be stuck wondering who actually holds your app.