Guides 31 August 2026 5 min read

Where your code lives is a business decision

Your software is an asset you probably cannot locate. Four ways companies lose access to their own code — and what owning it properly actually requires.

By the PearlFibers Team

Ask a company where its money is and you get an immediate answer: this bank, these accounts, this person signs. Ask the same company where its source code is and the answer often takes a week, three phone calls and a slightly nervous WhatsApp message to a developer who left in 2024.

That asymmetry is strange, because for a business that runs on custom software the repository is not a technical detail. It is the thing you paid for. Everything else — the running site, the app in the store, the platform your staff open every morning — is an output of it.

Four ways companies lose their own code

None of these involve anyone acting in bad faith. They are all drift.

1. It is on a personal account. The repository lives under a developer's individual account on a public platform. The company has no organisation, no billing relationship, no admin. When that person moves on, the asset moves with them — not because they stole it, but because nobody ever put it anywhere else.
2. There is exactly one admin. Perhaps it is in a company organisation, but one human holds the only owner role. Illness, resignation or a forgotten second factor and the company is locked out of its own account with no recovery path.
3. The pipeline is a laptop. The code is safe, but the knowledge of how it becomes a running system is not written down anywhere. Deployment is one person's terminal history. The repository survives; the ability to ship does not.
4. The bill stops. Card declines, expired payment methods, verification requests from an international provider that are awkward to satisfy from Iraq. Accounts get suspended over administrative friction far more often than over anything dramatic — and it always happens the week you need to deploy.

What "we own our code" actually has to mean

Ownership is not a ZIP file someone emailed you at handover. A ZIP is a snapshot with no history, no branches, no review record and no way to know which version is the one running in production. Real ownership is six things:

• The repository, with its full history. Every commit, every branch, every tag. History is how you find out when a bug appeared and what shipped with it.
• The pipelines. The build and deploy definitions, versioned next to the code, so shipping is a documented process rather than a person.
• The packages. Internal libraries published somewhere the company controls, not to a personal registry account.
• Access control you administer. You add and remove people, ideally through the same sign-in your staff already use, so an offboarding actually removes access everywhere.
• The secrets. Deployment keys and environment variables held by the company, rotated when someone leaves.
• A cheap exit. The ability to take all of the above elsewhere without a migration project — which is a property of the format, not a promise from a vendor.

Plain Git is the thing that makes an exit cheap

This last point deserves more attention than it usually gets. A Git repository is a standard, portable structure: clone it and you have every byte of history on your own disk. Any service that stores your code as plain Git can be left with a single command, because leaving is just cloning somewhere else.

What is not portable is everything a platform builds around the repository — issues, review threads, pipeline definitions in a proprietary syntax, package registries, permissions. That is where lock-in actually lives. The practical question to ask a vendor is not "can I export?" but "if I left next month, what would I lose that I cannot re-create?"

Cloud or your own building?

Both are legitimate. The decision is usually about who is asking the question rather than about technology.

The worst answer is the accidental one: nobody decided, so the code ended up wherever the first developer happened to have an account.

The five-minute audit

You do not need a consultant for this. Take five minutes and try to answer these out loud:

• Where is our source code right now, and whose name is the account in?
• Who has owner access — and is it more than one person still employed here?
• If our lead developer disappeared tomorrow, could we deploy a fix on Thursday?
• Is the deployment process written down, or is it in someone's head?
• When someone leaves, what single action removes their access to everything?
• Who pays the bill for the platform, and what happens if that card fails?

Any question you cannot answer in a sentence is a risk you are currently carrying without pricing it.

Why we built PearlGit

We built PearlGit because we needed all of the above for our own products first: pull requests with required reviewers and status checks that block a merge, CI/CD running where the code lives, package registries under the same permission model, and sign-in tied to the accounts our team already has.

Two design decisions matter most to a business. It is plain Git underneath, so your exit stays cheap and a migration from another platform arrives with history intact. And it runs either in our cloud or as the same binary inside your own VPC — the choice is yours to change later, not a fork in the road you take once. The interface is also fully localised to Arabic, more than four thousand strings with real right-to-left layout, so a team that thinks in Arabic can review code in Arabic.

Whichever way you go, decide it deliberately. The company that can answer "where is our code?" in one sentence is a company that can survive its own staff turnover — and that is a business property, not a technical one.