How do I make sure I dont lose my apps code?

Losing your app's code is like losing the building along with the blueprints, the contractor notes, and any memory of what was decided along the way. We have spoken with founders who handed development to an agency, paid for months of work, and then found themselves with a delivered product they could not access, modify, or transfer to anyone else, because they never owned the repository in the first place. That is a painful and avoidable situation.

Your code is a long-term asset, and it needs the same protection you'd give any other asset you own.

The question of how you protect your code sits inside a broader set of questions about ownership, access, and process. Getting those right from the start shapes how safely you can build, how easily you can hand off work between partners, and how much leverage you retain over your own product. None of it requires deep technical knowledge on your part. But it does require knowing what to ask for and what to insist on.

This article covers everything from the basics of version control through to what good handover looks like when you change development partner. Each chapter stands alone, so if you already understand the fundamentals, you can move directly to the parts most relevant to where you are right now.

What version control actually is and why it matters

Version control is a system that records every change made to your codebase over time, who made it, and when. Rather than a single file that gets overwritten each time a developer saves their work, a version-controlled codebase builds up a full history of changes, which you can browse, compare, and roll back through at any point.

Think of it as a very detailed log book for your product. Every time a developer makes a meaningful change and commits it to the repository, the system records what changed and attaches a message describing why. If a change breaks something, the team can look at exactly what was altered and revert it without guessing. If a feature was removed three months ago and you want it back, you can find the version of the code that contained it.

Beyond recovery, version control enables multiple developers to work on the same codebase at the same time without overwriting each other's work. It is the foundation on which everything else in modern development practice is built, including testing, deployment pipelines, and code review. Without it, a team of two or more developers is essentially working in conditions that make collaboration unreliable and mistakes very difficult to trace.

The infrastructure advantages go further than most founders realise. Being able to store your infrastructure as code and keep it in the same repository means you can spin up identical testing or review environments quickly, with the same configuration every time. That consistency is something a manual deployment process simply cannot replicate.

What happens if you skip it

A codebase without version control is a single point of failure. There is no history, no way to roll back a broken change, and no reliable record of what was done or why. If the developer who built it leaves, much of the context leaves with them. If a server fails or a file is accidentally overwritten, there is nothing to recover from.

Beyond the practical risks, the absence of version control makes it much harder to bring new developers onto a project. A good repository gives an incoming developer a readable timeline of the product's evolution. Without it, they are dropped into an undated archive with no narrative and no way to understand the decisions that shaped what they are looking at.

We have seen projects where code was emailed between collaborators, edited locally, and sent back, with different versions of the same files existing simultaneously across different machines. That kind of arrangement works until it does not, and when it stops working, the damage is often irreversible. There is no audit trail to reconstruct what the intended state of the code was before things diverged.

The costs compound too. Teams that have adopted version control report significantly fewer bugs than those working without it, which is consistent with what we observe when a project comes to us mid-build without any tracking history in place. Catching and fixing problems as they happen, commit by commit, is a different order of effort from untangling months of accumulated changes all at once.

Choosing a version control system

Git is the version control system used by the overwhelming majority of professional development teams. It is distributed, meaning every developer has a full copy of the repository on their machine, and it is supported by all the major hosting platforms. For practical purposes, the question for most founders is not which version control system to use, but which platform to host the Git repository on.

The three platforms worth knowing are GitHub, GitLab, and Bitbucket. All three support Git repositories and offer collaboration tools, code review workflows, and integration with deployment pipelines. The differences come in pricing structure, built-in automation features, and how well they integrate with other tools your team uses.

What matters more than the platform choice is the ownership of the account. The repository should live in an account registered to you or your company, with your developer or agency given access as a collaborator. The platform is almost interchangeable between competent teams. Who controls the account is not.

The repository should live in an account you own, with your developer given access as a collaborator.

Pick a platform your development team uses confidently and make sure you hold the login credentials for the account it lives in.

Branching strategies that protect your main codebase

A branch is a separate copy of the codebase that developers can work on without affecting the main version. When the work is ready and reviewed, it is merged back in. This means that new features, bug fixes, and experiments can all proceed in parallel without any of them touching the live product until someone deliberately approves the merge.

The most straightforward approach for most product teams is a two-branch model: a main branch that reflects what is in production, and a development branch where work-in-progress changes accumulate before being promoted. Individual features get their own short-lived branches off the development branch, and they only join the development branch once a peer has reviewed the code.

Protect your main branch by requiring at least one code review before any merge is allowed. Most platforms let you enforce this at the repository settings level, so it cannot be skipped accidentally.

More complex products sometimes adopt a three-tier model with a separate staging branch for pre-release testing, but for most early-stage apps, that adds process overhead before it adds value. Start simple and add structure when the team size or release cadence genuinely demands it.

The practical benefit of branching is that your main codebase is always in a known, working state. A developer who introduces a bug on a feature branch has not broken anything in production. That separation is what lets teams move quickly without the fear of irreversible damage, and it is one of the most important habits to establish from the first day of a project.

Name branches clearly so their purpose is obvious at a glance. Something like "feature/checkout-flow" or "fix/login-error" is far easier to navigate than "johns-branch" or "new-stuff".

Who owns the repository and the accounts it lives in

This is the question we see founders get wrong more than any other. A development agency builds your product, the code lives in the agency's GitHub organisation, and when the relationship ends, you find yourself negotiating for access to your own product. That situation is entirely preventable if you establish ownership before a single line of code is written.

On a social football product we worked on, the client held the App Store Connect Account Holder role because the account was registered in their name. We were given admin access to the majority of the account and set up three internal testing groups: one for our team, one for the client, and one for external QA testers. That structure gave everyone appropriate access without anyone holding more control than they needed. The client could see what was happening, we could manage the deployment pipeline, and the account stayed with the person who owned the product.

The same principle applies to your source code repository. Create the account yourself, in your own name or your company's name, before you engage a development partner. Then invite the agency or freelancer as a collaborator with the access level appropriate to their role. If the relationship ends, you revoke access. The code stays with you.

Do not accept an arrangement where a developer or agency insists on hosting the repository in their own account "for convenience". A competent partner has no difficulty working from a client-owned account. An arrangement that makes your code contingent on the relationship is a commercial risk, regardless of how the technical rationale is framed.

Access levels and why not everyone needs the keys

Every person who can access your repository represents a potential point of exposure. That does not mean keeping the team small for the sake of it, but it does mean giving each person only the level of access their role requires and reviewing that list regularly.

Most platforms offer at least three meaningful tiers of access. A read-only role lets someone view the code and history without being able to change anything. A contributor role lets someone push changes to branches but not to protected branches like main. An admin role gives full control, including the ability to change settings, delete branches, and manage other users' access.

1. Read access for stakeholders who need visibility but do not write code
2. Contributor access for developers working on feature branches
3. Admin access for the lead developer or technical director only
4. Owner access retained by the founder or company account

On the App Store side of the social football project, we saw what happens when access boundaries are not enforced. Because the client held full ownership of the App Store Connect account, they were able to bypass the testing group structure we had set up and manually send builds to whichever group they chose. It caused confusion during the deployment process and is a good illustration of why agreed access protocols matter as much as the technical permissions themselves.

Roles and responsibilities around the repository should be documented and agreed with your development partner before work begins, not worked out after a problem has already occurred.

Protecting sensitive data within your codebase

Secrets do not belong in source code. API keys, database credentials, payment provider tokens, and environment-specific configuration values should never be committed to a repository, including a private one. When they are, they become part of the history, and history is very difficult to fully scrub even if you catch the mistake quickly.

The standard approach is to use environment variables for anything sensitive. The code references a variable name, the actual value lives in a separate configuration file or a secrets management service, and that file is excluded from version control using a mechanism called a gitignore file. What gets committed is the shape of the configuration, not the values themselves.

According to Serverion, 61% of organisations have accidentally exposed secrets such as API keys in public repositories. That figure is almost certainly an undercount, because private repositories with overly broad access create the same exposure without ever appearing in a public search. A key that sits in a private repository accessible to twelve people is not a secret in any meaningful sense.

On the performance coaching survey app we built, the security model around the Firebase database was one of the most demanding parts of the project. Because we had made a deliberate early decision to skip a traditional API for the MVP, there was no intermediary layer between the client and the database. That meant we had to scrutinise every Firebase security rule very carefully, writing rules that controlled exactly which authenticated roles could read or write which data, at the collection level. Nothing was left at a default permission setting.

Run a secrets scanning tool against your repository before you make it accessible to anyone new. GitHub has a built-in secret scanning feature for repositories under its Advanced Security tier. GitLab includes it in its Ultimate plan. Several free standalone tools exist for smaller teams.

Backups, redundancy, and disaster recovery

A Git repository hosted on a cloud platform is already more resilient than a local folder on one developer's laptop, but it is not a backup in itself. Platform outages happen. Accounts get suspended. Accidental deletions do occur. A repository that exists in only one place is still a single point of failure.

The practical minimum is mirroring your repository to a second location. Most platforms support automatic mirroring, where every push to your main repository is replicated to a secondary location in real time. That secondary location can be a different cloud platform, a self-hosted Git server, or a storage service. The point is that if the primary location becomes unavailable, you have an up-to-date copy somewhere you control.

Beyond the repository itself, document your infrastructure configuration and store it in the repository too. Being able to store your infrastructure as code in the repository means you can spin up a new environment quickly, with the same configuration every time, rather than relying on someone to remember what settings were applied to the server that is no longer accessible. That consistency is one of the most practically useful things modern cloud tooling offers, and it transforms a disaster recovery scenario from a weeks-long reconstruction into something that can be done in hours.

Test your recovery process before you need it. Knowing that a backup exists is not the same as knowing that the backup restores correctly. A brief rehearsal of the restoration process, even once a year, is far better than discovering an untested assumption at the worst possible moment.

What good handover looks like if you change development partner

Changing development partner is a normal event in the life of a digital product. Agencies evolve, costs change, team capabilities shift, and founders sometimes simply want a different working relationship. What should never be a crisis is the handover of the codebase itself.

A clean handover includes a few specific things. The incoming team should receive full access to the repository, including its complete commit history and all branches, active or otherwise. They should receive documentation that covers the architecture, the environment configuration, the deployment process, and any decisions that shaped why the code is the way it is. They should also receive access to any third-party services the product depends on: cloud providers, analytics tools, push notification services, payment integrations, and anything else that is wired into the product.

Where ownership of the repository was correctly structured from the start, with the client holding the account and the agency working as a collaborator, handover is straightforward. The outgoing agency loses access, the incoming agency gains it, and the code never moves. Where the repository lived in the outgoing agency's account, the handover requires a migration, which adds time and introduces risk at a moment when you probably want neither.

A good incoming partner should run their own audit of the codebase before committing to a timeline or a budget. That is responsible practice, and a standard expectation of any professional engagement. A codebase has a history, and understanding that history before making promises about what can be built on top of it is how a new partner protects both themselves and you.

Before engaging a new development partner, confirm that you can export the full repository, including its history, from wherever it currently lives. A repository you cannot export freely is a repository you do not fully own.

Conclusion

Protecting your code is really about protecting your options. A well-managed repository, owned by you, with appropriate access controls, clean secrets handling, and a reliable backup, means you can move development partners, onboard new developers, roll back a broken release, or reconstruct an environment without any of those things becoming a crisis.

The practical steps are not complicated. Own the account your repository lives in. Give collaborators the access their role requires and no more. Keep secrets out of the codebase. Mirror your repository to a second location. Document your infrastructure and store it alongside the code. Agree on a branching strategy that keeps your main codebase stable.

None of this requires you to understand the code itself. It requires you to ask the right questions before work starts, and to treat the answers as commercially significant, because they are. The code your development partner writes on your behalf is an asset you are paying to build. How it is stored, who can access it, and what happens to it when the relationship changes are ownership questions, and they have your name on them.

If you are starting a new product or reviewing how your current codebase is structured, let's talk about your app and how it's set up.

Frequently Asked Questions