Owning an app someone else built: the takeover checklist for the repository, accounts, domain, keys and hosting

Owning an app someone else built takes more than the code in your repository. It takes the accounts the app runs on, each with you as owner: hosting, database, domain, payments, email and the AI provider. It ends with rotating every key the previous builder held: in three of the 21 third-party apps I audited in June and July 2026, a real secret sat permanently in git history.

The takeover checklist for owning an app someone else built

Owning an app someone else built comes down to ten things you can prove: the code in your repository, the hosting in your team, the domain in your registrar, every provider account in your name, the keys they held rotated, a deploy from a fresh clone, a working local setup, the documents, the developer removed, and a signed handover.

Those three apps came out of a small group: 21 third-party apps I chose to audit in June and July 2026. They are a selected set, not a random sample, so three in 21 is not a rate you can apply to AI-built apps in general. The secrets were a webhook signing secret, a live AI-provider key, and a Stripe test key with its webhook secret. The list below is the owner’s half of what a developer handoff looks like, the half you can test yourself after the builder has gone.

Two questions come before this list, and each has its own article. Which accounts must be in your name, with a check for each that takes under a minute, is the job of do I own my app. The rule each platform sets for moving an account, and why a login is not the owner role, sits under when the developer left the project unfinished. Here you get the takeover in order, with a test for every row.

Technical ownership is these ten rows, done in this order and each one proven. The order matters: keys are rotated only once the accounts are yours, and the developer comes out only once the app deploys without them.

Each row needs a test you can run without the builder’s help and a piece of evidence you can keep. The table is my working rule for both.

Getting the keys from an app developer is rows 4 and 5 together: the accounts come to you first, and then each key you were handed gets rotated, because the copy you received is one the developer has too. To take over an existing codebase as its owner, this list is the whole job; the engineer’s first month inside that code is a different piece of work, a legacy code takeover. An app rescue project starts from the same ten rows, since nothing gets fixed for long in an app you cannot deploy yourself.

Seen from the owner’s seat, a project takeover checklist is these ten rows. From the agency’s seat it is how to hand over an app to a client, and bringing in a new person to carry on the work is hiring a developer to take over your project.

How to fill it in

Each group below has the steps, the mistake people make, and what to record. The vendor behavior in these steps comes from each vendor’s own docs, not from anything I ran. The rules for moving each account belong to the two articles named above and are not repeated here.

Getting the code out of the builder

Exporting an app to git puts the code in a version control system, which tracks the history of changes to it, and GitHub is one of the services that “hosts Git repositories”. GitHub’s explanation of git covers the basics if the terms are new.

1. Decide which GitHub account or organization of yours will own the code.
2. Connect the builder to it, letting the builder create the repository if that is its route, or have the developer transfer their repository to you. Who is allowed to make that move is the platform’s rule, set out in the unfinished-project article above.
3. Clone it to your own machine and check that the commit history came with it.

Every builder has its own route out. For Lovable code, follow how to export Lovable code. The data in a Lovable Cloud backend is a separate job: exporting a Lovable Cloud database. A Base44 app has its own Base44 export code steps, and a Replit app has its Replit export route. To export and own the code from an AI-generated app on any other builder, start with can you export your code from an AI app builder, which says which builders export at all and what an export leaves behind.

The mistake is leaving the repository in the developer’s account with you added as a collaborator. That seat is access they gave you, so it is still theirs to take back. Record the repository address and the date it moved.

Getting the accounts

Move the accounts in this order: hosting, database, domain, payments, email, AI provider, error tracker. That is my working rule: the ones that can switch the product off go first.

1. The person who holds the owner role on an account hands that role to your own login, by whatever route the platform sets.
2. Sign in as yourself and confirm the owner role, not a member or admin seat.
3. Write down the date the role moved and who holds it now, as a line in your provider inventory.

The steps to transfer accounts to the founder differ on every platform: the unfinished-project article has each platform’s rule, including why a login is not ownership, and the ownership article has the list of accounts that count. The mistake is stopping at a login.

Rotating the keys the builder held

1. Wait until rows 2 to 4 are done and the accounts are yours.
2. List every key the previous builder created, saw or could read.
3. Replace each key that was created under the developer’s own provider account with a new one created in yours.
4. Rotate the keys in accounts you keep, and expire each old key once the app runs on its replacement and nothing uses the old one any more.

Rotating before the accounts move leaves the new keys where the builder can still see them, which is why step 1 waits. The list in step 2 is my reading of the rule in the article on hiring a developer to take over: rotate a credential that “was exposed, may have been exposed, or was available to someone whose access you can no longer trust”, and not every key “merely because a person joined or left when that person never had the credential”. If the builder set the app up, that rule covers the keys it runs on, because they could read them.

A key in an account you keep does not stop working because the person who created it left (my reading). On Stripe, for example, “Code that uses the expired key can no longer make API calls”, and “When you rotate a key in the Dashboard, both the old and new keys work for up to 7 days.” Until the old key expires, the builder’s copy works as well. Stripe’s advice is to check the old key’s request logs and “expire it only after its request volume has been at zero for a few hours or days.” My working rule in a takeover is to keep that window as short as the logs allow. The Expiration dropdown you see when you rotate sets it, and “If you choose Now, the old key is deleted.” Stripe’s guide to API keys has the click path.

The three apps in the opening line are the reason to look past today’s files and into the history. Finding what the builder left there is secret scanning; the rotation order and the rehearsal are row 5’s job. The mistake is rotating on day one while the builder still holds an owner seat. Record each key, where it lives, the date it was replaced, and the first successful request on its replacement.

Running it from your own clone

1. Clone your repository onto a clean machine.
2. Copy the environment example into place and fill it with your own values.
3. Run the one setup command the guide names, and open the app.
4. Push a small change and let your own pipeline deploy it.

Take a founder who has the repository and the provider accounts in their own name and runs the first deploy from a fresh clone. The deploy stops at a step that still depended on the builder tool the app was generated in. Until a fresh clone deploys with no step that needs the builder tool, part of the app still belongs to the tool, and an app that only exists inside the builder tool cannot be reviewed, rolled back, or handed to another engineer.

The mistake is a deploy step that still calls the builder tool or the developer’s machine, or runs on a token in the developer’s own name; my reading is that it stops working the day row 9 removes them. Record the date, the commit, and a note of anything the guide missed.

Offboarding the developer

Onboarding gives a person the access their work needs, and offboarding takes every piece of it back. In the onboarding and offboarding process for one app, the offboarding half happens on a single day:

1. Remove the developer from every account and every repository on the same day, and record the date.
2. Delete the deploy keys and API tokens they created in your accounts. My reading: removing their seat does not delete what they created, and a token that lives in their own account is not yours to revoke; you can only remove the access it had.
3. On Stripe, check the sandboxes as well as the live account. Stripe says “You can assign a different role in a sandbox than the one the user holds in other sandboxes or in your live account or organization”, and a member is removed in “the live account, live organization, sandbox, or organization sandbox where that user has a role assignment”.
4. Put any open questions to the developer in writing, with the date you asked.

For the next developer the same list runs in reverse: each seat is named when it is given, so each one can be taken back on one day. For a single app, an IT discovery checklist is the provider inventory from row 4.

A filled example

Assume one app. A contractor built it on Lovable, with a Supabase backend, Stripe for payments and an AI provider key, and the code sits in the contractor’s GitHub account. This is an illustration with stated assumptions, not a client’s story; how each account moves is in the Lovable export article and the unfinished-project article above.

How to verify the result

Ownership has one combined test: remove the previous builder from every account and repository, then deploy a visible change from a fresh clone, take a test payment, and read a new log line. If any of the four fails, one of the ten rows is not done yet.

Keep the proof of each: the removal list that shows the builder gone, and the deploy log naming the commit that went out. For payments, a production app on live keys takes no test-mode payment, so take the test payment in the provider’s test mode on the staging deploy, and then find the live key’s first successful request after rotation in the provider’s request logs, which Stripe opens from each key’s menu. The new log line carries its own timestamp. Write down all four with the date.

When we run the Production Hardening Sprint, rows 4 to 7 each have a written verify step of their own. Deliverable 2.8 is verified this way: “Produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed.” For 2.6: “Rehearse rotation with a test credential and record the affected services and checks.” For 7.11: “Deploy a fresh clone to staging through the pipeline with no step that depends on the generating tool.” For 10.10: “Go from clone to running application on a new machine by following the guide alone.”

Where the sprint does this

The verify steps above check the work; deliverable 2.8 is the work itself, and in it we “Move every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, with the founder as the owner role, billing in the founder’s name, and any previous builder removed.” At handover you receive a readiness report and technical due diligence pack, with the architecture diagram and data model in it, and instructions for releases, backups, recovery, and incident response. Every item is recorded in the production readiness report, which has to “Account for all 123 IDs; keep failures visible until resolved and explain genuine non-applicable items.” Hosting, paid tools, and API usage remain in your accounts. Each deliverable is listed in the published scope.

Common questions about taking over an app

How do I transfer an account to another?

The person who holds the owner role on the account hands that role to your account and is then removed from it, and you record the date as a line in your provider inventory. Who may move each platform’s account, and what to do when the holder will not, is covered in the article on a developer who left a project unfinished.

Is it safe to give your API key?

It is safer not to: give a developer their own seat in the account and let them create their own keys, rather than handing over yours (my reading). A key you did share is one they could read, so rotate it when their access ends. Stripe’s docs also say “Don’t share keys over email, chat, or other unencrypted channels.”

Will an API key expire?

No, not just because the person who created it left, if the key lives in an account you keep (my reading). On Stripe, a key stops making API calls once it is expired, and a rotated key lasts until the expiration you pick at rotation. Other providers set their own rules, so read each provider’s docs before assuming a key has lapsed.

What’s the difference between git and GitHub?

Git records the history of your code inside the repository, and GitHub is a service that stores repositories online and adds tools such as pull requests and code review. The Pro Git book says Git “thinks about its data more like a stream of snapshots”: at each commit, it takes a picture of what all your files look like. For a takeover, the difference matters in one place: the repository on GitHub has to sit under your account, not the developer’s.