V
Vikrant Bhalodia
Guest
Most companies think they own their software because they paid for it. The real test comes when the people who built it are suddenly unavailable. If your team cannot access the source code, cloud account, deployment credentials, app store accounts, documentation, or third-party services without the vendor, you may own the product on paper while lacking practical control over it.
Imagine this. It is Monday morning and your development partner has stopped responding. Their website is down. Emails bounce. Your application is still online, customers can still sign in, and nothing appears broken.
Then someone asks a simple question:
“Can we deploy a fix ourselves?”
Nobody in the room knows. That is when software ownership stops being a contract phrase and becomes an operating problem.
Source-code ownership gets most of the attention because it is easy to understand. If another company built your application, you should know where the code lives, who owns the repository, and whether your organization has administrator access.
A ZIP file sent at the end of a project is not the same thing as controlling the working repository. The repository may contain version history, branches, release tags, automated workflows, configuration files, issue references, and other context a replacement team may need.
GitHub supports repository transfers between users and organizations, but the transfer requires the right permissions. If the only administrator belongs to a vendor that no longer exists, something that should have been routine can turn into a serious recovery problem.
The safer ownership model is usually simple: the client organization owns the main repository, while outside developers receive the access they need to work.
Having the source code does not mean you can keep the product running. The application may depend on AWS, Azure, Google Cloud, Cloudflare, Firebase, a managed database, object storage, email delivery, queues, monitoring tools, and a collection of smaller services. Someone created those accounts. Someone controls billing. Someone can reset passwords. Someone can add or remove administrators.
Consider AWS. Its documentation states that the AWS account root user has complete access to the account's services, resources, and billing information.
If the root account was created using an agency-controlled email address, the client may depend on that agency for the highest level of control over its own production environment.
The same issue appears in less obvious places. A domain may be registered through the vendor's account. DNS may sit inside its Cloudflare workspace. Production secrets may be stored in a tool nobody on the client's staff can access. The software can belong to you while the keys to the building belong to someone else.
Mobile products add another layer because Apple and Google maintain their own developer-account systems. Google Play has a formal process for transferring apps between developer accounts. Some information moves with the app, while other items, such as certain reports and permission settings, may not. The transfer also assumes that the relevant accounts are still active and accessible.
That creates an obvious question for any business with a mobile product: whose developer account was used to publish the app?
If the answer is an employee's personal account or a third-party vendor's account, ownership should be cleaned up before there is a crisis.
This is boring administrative work until the day you need an urgent release and discover that the person with the right access left two years ago.
A new team can receive the entire codebase and still spend weeks trying to understand how the product actually works.
What services does it depend on? How is production released? Which scheduled jobs run in the background? Where are backups stored? Which environment variables are required? Who manages the SSL certificates? What happens when a payment fails? Which external API would stop the business if it went offline?
Good documentation does not need to explain every line of code. It needs to give the next capable team enough context to operate the product safely.
This connects with a broader software problem around technical debt and lost decision history. HackerNoon has previously covered how Architectural Decision Records can preserve the reasoning behind technical choices, rather than forcing future teams to reconstruct those decisions from the code.
A system that only one supplier understands is not fully transferable, even if every file has been handed over.
Many products depend on services that rarely appear in an ownership discussion. Think about Stripe, Twilio, SendGrid, Firebase, OpenAI, analytics platforms, error monitoring, customer-support tools, mapping APIs, push-notification services, certificate providers, CI platforms, domain registrars, and code-signing accounts.
If those services were created using a vendor-controlled email address, the product has inherited an operational dependency on that vendor.
Vendor lock-in is usually discussed in terms of cloud platforms or proprietary technology. A HackerNoon discussion of vendor lock-in in low-code platforms makes a related point: access to the code and freedom to deploy elsewhere affect whether a business can truly move away from a supplier.
Account ownership creates another form of lock-in. You can replace a vendor's developers and still discover that you cannot replace the vendor's access.
Legal ownership and operational ownership are two different things. A contract can state that intellectual property transfers to the client after payment. That may be useful, but it does not automatically move a GitHub repository, cloud tenant, domain, database backup, signing certificate, or app-store account into the client's control.
The exact legal position also varies by contract and jurisdiction, so software buyers should get proper legal advice on intellectual property clauses rather than assuming an invoice answers the question. On the technical side, handover terms should be equally clear.
These risks are easier to address before development begins. When evaluating an outside development partner, businesses should look beyond delivery timelines and pricing and ask who will control the code, accounts, documentation, and intellectual property if the relationship ends.
Engineering teams sometimes talk about the “bus factor”: how many people could disappear before a project loses critical knowledge.
Businesses should apply the same idea to suppliers. Ask what would happen if your software vendor vanished tomorrow. Not after a planned 60-day handover. Not after three knowledge-transfer calls. Tomorrow.
If several answers are “no,” the business has a continuity gap.
You do not need to bring every technical task in-house. Outside teams can manage infrastructure, releases, support, and maintenance while the client retains control over the underlying assets.
At minimum, the business should know who controls:
There should also be more than one trusted person with access to business-critical systems.
Accounts tied to one employee's personal email address create unnecessary risk, even when that employee has been with the company for years.
A good software relationship should survive the end of the relationship. That does not mean expecting a vendor to fail. Companies close, merge, get acquired, change direction, lose key staff, raise prices, or simply stop being the right partner for a product.
Your software should still be able to move when your business needs it to move. Real software ownership is not just possession of source code. It is the ability to operate, maintain, secure, transfer, and continue the product without requiring permission from a company that may no longer be there.
The easiest time to establish that control is when the project begins. The second-best time is while everyone is still answering their email.
Imagine this. It is Monday morning and your development partner has stopped responding. Their website is down. Emails bounce. Your application is still online, customers can still sign in, and nothing appears broken.
Then someone asks a simple question:
“Can we deploy a fix ourselves?”
Nobody in the room knows. That is when software ownership stops being a contract phrase and becomes an operating problem.
Owning the Code Is Only the First Layer
Source-code ownership gets most of the attention because it is easy to understand. If another company built your application, you should know where the code lives, who owns the repository, and whether your organization has administrator access.
A ZIP file sent at the end of a project is not the same thing as controlling the working repository. The repository may contain version history, branches, release tags, automated workflows, configuration files, issue references, and other context a replacement team may need.
GitHub supports repository transfers between users and organizations, but the transfer requires the right permissions. If the only administrator belongs to a vendor that no longer exists, something that should have been routine can turn into a serious recovery problem.
The safer ownership model is usually simple: the client organization owns the main repository, while outside developers receive the access they need to work.
The Cloud Account May Matter More Than the Code
Having the source code does not mean you can keep the product running. The application may depend on AWS, Azure, Google Cloud, Cloudflare, Firebase, a managed database, object storage, email delivery, queues, monitoring tools, and a collection of smaller services. Someone created those accounts. Someone controls billing. Someone can reset passwords. Someone can add or remove administrators.
Consider AWS. Its documentation states that the AWS account root user has complete access to the account's services, resources, and billing information.
If the root account was created using an agency-controlled email address, the client may depend on that agency for the highest level of control over its own production environment.
The same issue appears in less obvious places. A domain may be registered through the vendor's account. DNS may sit inside its Cloudflare workspace. Production secrets may be stored in a tool nobody on the client's staff can access. The software can belong to you while the keys to the building belong to someone else.
App Store Ownership Has Its Own Rules
Mobile products add another layer because Apple and Google maintain their own developer-account systems. Google Play has a formal process for transferring apps between developer accounts. Some information moves with the app, while other items, such as certain reports and permission settings, may not. The transfer also assumes that the relevant accounts are still active and accessible.
That creates an obvious question for any business with a mobile product: whose developer account was used to publish the app?
If the answer is an employee's personal account or a third-party vendor's account, ownership should be cleaned up before there is a crisis.
This is boring administrative work until the day you need an urgent release and discover that the person with the right access left two years ago.
Documentation Is Part of Ownership Too
A new team can receive the entire codebase and still spend weeks trying to understand how the product actually works.
What services does it depend on? How is production released? Which scheduled jobs run in the background? Where are backups stored? Which environment variables are required? Who manages the SSL certificates? What happens when a payment fails? Which external API would stop the business if it went offline?
Good documentation does not need to explain every line of code. It needs to give the next capable team enough context to operate the product safely.
This connects with a broader software problem around technical debt and lost decision history. HackerNoon has previously covered how Architectural Decision Records can preserve the reasoning behind technical choices, rather than forcing future teams to reconstruct those decisions from the code.
A system that only one supplier understands is not fully transferable, even if every file has been handed over.
Third-Party Accounts Can Quietly Become Single Points of Failure
Many products depend on services that rarely appear in an ownership discussion. Think about Stripe, Twilio, SendGrid, Firebase, OpenAI, analytics platforms, error monitoring, customer-support tools, mapping APIs, push-notification services, certificate providers, CI platforms, domain registrars, and code-signing accounts.
If those services were created using a vendor-controlled email address, the product has inherited an operational dependency on that vendor.
Vendor lock-in is usually discussed in terms of cloud platforms or proprietary technology. A HackerNoon discussion of vendor lock-in in low-code platforms makes a related point: access to the code and freedom to deploy elsewhere affect whether a business can truly move away from a supplier.
Account ownership creates another form of lock-in. You can replace a vendor's developers and still discover that you cannot replace the vendor's access.
Contracts Matter, but They Cannot Replace Access
Legal ownership and operational ownership are two different things. A contract can state that intellectual property transfers to the client after payment. That may be useful, but it does not automatically move a GitHub repository, cloud tenant, domain, database backup, signing certificate, or app-store account into the client's control.
The exact legal position also varies by contract and jurisdiction, so software buyers should get proper legal advice on intellectual property clauses rather than assuming an invoice answers the question. On the technical side, handover terms should be equally clear.
These risks are easier to address before development begins. When evaluating an outside development partner, businesses should look beyond delivery timelines and pricing and ask who will control the code, accounts, documentation, and intellectual property if the relationship ends.
The Bus-Factor Test Works for Vendors Too
Engineering teams sometimes talk about the “bus factor”: how many people could disappear before a project loses critical knowledge.
Businesses should apply the same idea to suppliers. Ask what would happen if your software vendor vanished tomorrow. Not after a planned 60-day handover. Not after three knowledge-transfer calls. Tomorrow.
- Could someone inside your company access the repository?
- Could you log into the production cloud account?
- Could you rotate credentials?
- Could you renew the domain?
- Could another development team deploy a release?
- Could you retrieve a current database backup?
- Could you publish an urgent mobile update?
- Could you identify every paid service the product depends on?
If several answers are “no,” the business has a continuity gap.
What You Should Actually Control
You do not need to bring every technical task in-house. Outside teams can manage infrastructure, releases, support, and maintenance while the client retains control over the underlying assets.
At minimum, the business should know who controls:
- Source-code repositories and administrator roles
- Cloud accounts and billing ownership
- Domains and DNS
- Databases and backups
- App-store developer accounts
- CI and release systems
- Production secrets and certificates
- Third-party APIs and SaaS accounts
- Analytics and monitoring accounts
- Design files
- Technical documentation
- Intellectual property rights
- Current technical contacts and escalation paths
There should also be more than one trusted person with access to business-critical systems.
Accounts tied to one employee's personal email address create unnecessary risk, even when that employee has been with the company for years.
The Best Handover Happens Before You Need One
A good software relationship should survive the end of the relationship. That does not mean expecting a vendor to fail. Companies close, merge, get acquired, change direction, lose key staff, raise prices, or simply stop being the right partner for a product.
Your software should still be able to move when your business needs it to move. Real software ownership is not just possession of source code. It is the ability to operate, maintain, secure, transfer, and continue the product without requiring permission from a company that may no longer be there.
The easiest time to establish that control is when the project begins. The second-best time is while everyone is still answering their email.