How do I keep control of the code and accounts behind my AI-built app?

Keep operational control by knowing where the code lives, who administers every important account, and how another authorized person can run the app. Repository access alone does not provide control of the domain, database, hosting, identity provider, or integrations. Agree those responsibilities before the project becomes business-critical.

GitHub's repository-transfer documentation explains how repository administration can move between owners, subject to its requirements. A transfer is one account-management action, not a complete handover of the application's operating setup.

Which accounts should we inventory?

Follow the application from the customer's URL to the systems doing the work. Record the domain registrar, DNS, hosting, repository, database, file storage, authentication, email delivery, payment provider, and any AI or automation services in use.

For each one, identify the business owner, administrator, billing contact, access method, and recovery process. Use supported access roles instead of spreading one shared password among suppliers.

A small app may use only a few services. The inventory should reflect the actual architecture, not a long generic checklist copied into every handover.

What happens if the developer leaves?

Ask a second authorized person to locate the repository, follow the setup notes, and explain the deployment process. Check that they can reach the relevant account administrators without relying on a former supplier's personal email.

If the app cannot be operated without one person's private account, identify the supported transfer or replacement path before the relationship changes.

Is source-code access the same as legal ownership?

No. Operational access and legal rights are different questions. The agreement and relevant licenses need to state what rights apply to custom work, third-party components, assets, and platform services. Have the responsible commercial or legal reviewer examine those terms.

Avoid assuming that every line in a generated repository is exclusively yours to license. Applications commonly include open-source dependencies and third-party assets. Maintain a record of the components and the terms relevant to the intended use.

This article focuses on practical control: ensuring your business can access, operate, and maintain the systems it depends on.

What should a handover acceptance check include?

Verify access directly from the receiving team's accounts rather than relying on a developer's screen share. Confirm which secrets must be replaced or transferred through an approved mechanism, and test the affected connections after any change.

Record ongoing supplier access and remove what is no longer needed. Keep an owner for renewals, bills, and alerts so a service does not stop because a notification reached an unused mailbox.

Revisit the inventory when a new integration is added. An app can begin under clear business control and gradually accumulate unrecorded dependencies through everyday feature work.

Make the app transferable before you need a transfer

Bring the repository and a list of the services you know about. Discuss a handover and maintenance review to document the operating setup and identify access gaps your team should resolve.

Frequently asked questions

Should a developer use their own hosting account?

Agree the ownership and support arrangement explicitly. If supplier-managed hosting is appropriate, document access, billing, recovery, and the process for moving the app later.

Do we need all production passwords?

Use supported roles and controlled secret-management processes. The goal is authorized business control and recovery, not distributing credentials to everyone involved.

Can we leave the code in the app builder?

Assess the platform's access and continuity arrangements for your requirements. Confirm how the responsible team will inspect, maintain, and recover the application if the current working arrangement changes.