How to Own Your App Source Code (and Prove It Is Complete)

Legal ownership of app code is decided by your contract. Practical ownership is decided by where the code lives, whether it is complete, and whether anyone other than the original developer can actually use it. Plenty of Nigerian businesses hold an assignment clause and a zip file, and discover at the worst moment that the two do not add up to a working app.

This guide deals with the operational side: what the code actually comprises, how to take possession of it as it is written, how to test that what you received is complete, and what to do if the handover never happened.

What "your app source code" actually includes

Businesses often ask for "the code" and receive only the mobile app project, which is typically the smaller half of the work. A complete handover covers everything needed to rebuild and run the product.

Ask for this list by name in the contract. "Source code will be provided at project completion" is too vague to enforce.

Repository ownership: the mechanism that makes this simple

Everything above becomes straightforward if you do one thing at the start: create the code repository under an account owned by your business, and add the developer as a collaborator.

Why this single step does most of the work:

• The code accumulates in your possession as it is written, rather than being handed over in one event that may never happen.
• Commits give you a verifiable progress signal without reading any code.
• If the relationship ends abruptly, the work to date is already yours.
• Multiple developers can be added or removed without renegotiating anything.
• It removes the awkward conversation entirely, because there is nothing to hand over.

Set it up with a company email address as the account owner, enable two-factor authentication, and make sure a director holds recovery access. Add a requirement to the contract that the developer commits work at least weekly to that repository, and that the final milestone includes the complete history.

Securing it in the contract

Alongside the repository arrangement, the agreement should contain an express intellectual property assignment of the custom code, designs and documentation to your company, effective on final payment. Paying an invoice does not by itself transfer copyright: in most copyright systems the creator is the first owner unless there is an employment relationship or a written transfer. Nigeria's framework was updated by the Copyright Act 2022, and a Nigerian intellectual-property lawyer should confirm the formalities for your situation. This article describes commercial practice, not legal advice.

The build test: proving the code is complete

This is the step almost nobody takes, and it is what separates real ownership from a false sense of it.

A build test means: an independent developer takes the repository, follows the documentation on a machine that has never touched the project, installs the dependencies, configures the environment, builds the app and runs it against a fresh backend deployment. If they can do that, you own something usable. If they cannot, you have a problem you want to find while the original developer is still engaged and still owed money.

How to run it:

1. Book it as a milestone activity, ideally before the final payment or the retention release.
2. Use a developer who has not worked on the project — a short paid engagement, indicatively ₦100,000–₦500,000 depending on complexity, is cheap insurance on a multi-million naira build.
3. Give them only what you hold: the repository, the documentation and the credentials list. No informal help from the original team during the test.
4. Ask them to produce three things: an installable app build, a running backend, and a list of anything missing or undocumented.
5. Have the gaps closed by the original developer before releasing the retention.

Common findings: missing environment variables, an undocumented manual step in deployment, a dependency available only from a private account, hard-coded credentials, or a backend that was never committed at all. All are fixable while the contract is live and expensive afterwards.

Signing keys, certificates and store accounts

Source code alone does not let you update a published app. Two other things control that.

• The Android signing key (keystore). Google Play requires updates to be signed consistently with the original app. Losing access to the key, or leaving it with a developer who will not release it, can prevent you from updating your own listing. Where Play App Signing is used, Google holds the app signing key while you manage an upload key; understand which arrangement your app uses and confirm the current process in Google's documentation.
• Apple certificates and provisioning profiles. These belong to the Apple Developer Program account. If the account is yours, certificates can be regenerated; if it belongs to the developer, you are dependent on them.

Practical requirements to set at kick-off:

• Google Play and Apple Developer Program accounts registered to your business, with your staff as account owners. Google Play developer registration has historically been a one-time US$25 fee and the Apple Developer Program an annual fee, historically US$99; verify current fees and verification requirements directly with each platform.
• The keystore file and its passwords delivered to you, stored securely, with an offline backup held by a director.
• Certificates and profiles created under your Apple account.
• A written note of which signing arrangement is in use and how a replacement key would be handled.

Third-party libraries, licences and what you cannot own

Almost every app is built partly from open-source and commercial components, and you do not own those. You use them under their licences, which is normal and legitimate — but it should be documented.

What to require:

• A written inventory of third-party libraries, SDKs, templates and paid components, with the licence type for each.
• A warranty in the contract that nothing pirated or improperly licensed has been used.
• Licence keys registered to your business for commercial components, with renewal dates and costs.
• A note of any copyleft-licensed components, since some open-source licences carry obligations if you distribute modified code. Ask your developer to flag anything that affects how you may use or distribute the app, and take professional advice if your product is commercial and heavily dependent on such components.

The practical risk is not usually legal action; it is a paid SDK licensed to the developer rather than to you, which stops working when the relationship ends.

Documentation that makes the code usable

Code without documentation is code you will pay someone to relearn. Require these as deliverables, updated at each milestone rather than promised at the end:

• README and setup guide: how to install dependencies and run the project locally.
• Environment variables list: every setting the system needs and what it does, with the secrets themselves kept in your credentials vault.
• Deployment guide: how to push a change to staging and production, step by step.
• Architecture overview: two pages explaining the main components, how they talk to each other and where data lives.
• Database notes: the schema, how migrations are run, and backup arrangements.
• Third-party services list: each account, what it is used for, who holds it, and the renewal date.
• Release process: how a build is produced, signed, submitted and rolled back.
• Known issues and limitations: an honest list saves the next developer weeks.

A simple test of adequacy: could a competent developer who has never seen your project get it running from the documentation alone? That is exactly what the build test measures.

Source code escrow: when it is worth it

Escrow means an independent third party holds a copy of the code, released to you if defined events occur — the vendor ceasing to trade, for example, or failing to support the system.

It is worth considering when:

• The system is critical to your operations and a long outage would be materially damaging.
• The vendor retains ownership because you licensed a product rather than commissioning a custom build.
• You have a genuine reason not to hold the code directly, such as a licensed platform with custom modules.

It is usually unnecessary when you already hold the repository, which is the case for most Nigerian SME app projects if the arrangement is set up properly at the start. Escrow adds cost and administration, and a stale deposit that is never updated provides little protection. If you do use it, define the release triggers precisely, require regular deposits, and verify that what is deposited actually builds.

The code handover acceptance checklist

Use this before the final payment or the release of retention.

• Repository under your company account, with full commit history
• Mobile app source for every platform in scope
• Backend and admin dashboard source in the same or linked repositories
• Database schema, migrations and a sample export
• Infrastructure and deployment configuration
• Environment variables documented, with secrets in your vault
• Android keystore or upload key, with passwords and an offline backup
• Apple certificates and profiles under your developer account
• Google Play and Apple accounts owned by your business
• Third-party library and licence inventory
• Cloud, database, notification and messaging accounts in your name
• API keys for all third-party services, held by you
• Documentation set as listed above
• Independent build test passed, with findings closed
• Signed IP assignment covering code, designs and documentation
• Written confirmation that vendor copies of your data have been deleted

If you never received the code: recovery options

1. Check the contract. An IP assignment and a source code delivery clause give you a clear written basis for the request. Read them before you write.
2. Ask plainly, in writing. A calm email requesting the repository, keys and documentation, referencing the contract, resolves many cases. Set a reasonable deadline and keep proof of delivery.
3. Establish what exists. Ask an independent developer to assess whatever you can access — the live backend, the published app, any files you hold — so you know whether you are recovering a complete system or a fragment.
4. Secure the accounts you can reach. Cloud hosting, database, store accounts, payment gateway, notification services. Change passwords and remove the vendor where you have authority.
5. Take legal advice where the sums justify it. A solicitor's letter referencing the assignment clause frequently produces the handover.
6. Report suspected fraud to the Nigeria Police Force, or the EFCC for online financial fraud, with your documentary evidence.
7. Weigh rebuild against recovery. Where the codebase is incomplete or poorly written, a fresh build with a properly structured contract can be faster and cheaper than untangling the old one. Get that assessment in writing before deciding.
8. Fix the arrangement for next time. Company repository, staged payments, documentation at each milestone, keys in your custody.

Example (hypothetical): a logistics app changes developers

Example (hypothetical). A Lagos courier business built a driver and customer app two years ago for an indicative ₦11,000,000. The original agency is winding down and recommends another firm.

The operations director does not simply forward a zip file. She runs a transition:

• Confirms the repository is under the company's account and that the history is complete, including the backend and the admin dashboard.
• Commissions an independent developer for an indicative ₦250,000 to run a build test: clone, install, configure, build the Android app, deploy the backend to a clean environment.
• The test surfaces four gaps: an undocumented manual database step during deployment, a maps API key registered to a staff member who has left, a paid charting component licensed to the old agency, and no record of the keystore passwords.
• Because the old agency is still engaged for the transition, all four are resolved: the deployment step is documented, the API key is reissued under a company account, the charting licence is purchased in the company's name for an indicative ₦180,000 per year, and the keystore and passwords are delivered and backed up offline.
• Only then does she release the final transition payment and introduce the new firm, who take over with documentation that has been proven to work.

Had she skipped the build test, each of those four items would have surfaced during the first urgent bug fix, with no leverage and no one to ask.

What changes for Nigerian businesses

• Code on personal laptops is common. Small teams often work without a shared repository. Insisting on a company repository from day one costs nothing and solves most handover problems before they exist.
• Developer mobility is high. Experienced Nigerian developers frequently move roles or relocate. Design for turnover: repository, documentation and keys held by the business.
• Dollar-billed services. Cloud hosting, notification services, maps, SMS and AI APIs are billed in US dollars, often on a card. Ensure these accounts and payment methods belong to the business, or services can be interrupted when someone leaves.
• Store account ownership is frequently overlooked. Apps published under an agency's developer account are still common. Registering your own accounts early avoids a transfer process later.
• Informal agreements dominate small projects. Even where the work was arranged over WhatsApp, a short written assignment and a repository invitation can be added at any time — and it is far easier to arrange while the relationship is good.
• Data protection duties travel with the data. Where a vendor holds copies of your customer data, your obligations under the Nigeria Data Protection Act 2023 remain yours. Require written confirmation of deletion at the end of an engagement, and check the Nigeria Data Protection Commission's current guidance.
• Budget for continuity, not just the build. Annual app maintenance commonly runs at an indicative 15–25% of the build cost, and a codebase nobody else can pick up raises that figure sharply.

Mistakes to avoid

• Accepting a zip file as handover. Without the history, documentation and keys, it may not be usable.
• Letting the repository sit under the developer's account. Ownership follows whoever created it.
• Skipping the build test. It is the only way to know whether what you hold actually works.
• Forgetting the backend. The app is the visible part; the server is where most of the work is.
• Leaving the keystore with the developer. It controls your ability to update your own app.
• Publishing under the vendor's store account. Listings, reviews and update rights should be yours.
• No documentation requirement. Documentation promised at the end is documentation you may never see.
• Paying the retention before verification. Keep leverage until the code has been proven.
• Assuming payment transfers copyright. It does not; an express assignment clause does.

Conclusion

Owning your app source code is mostly a matter of arrangements made before the first line is written: a repository under your company's account, an assignment clause in the contract, documentation due at each milestone, and store accounts and signing keys registered to your business. The step that turns those arrangements into certainty is the build test — an independent developer proving that what you hold can actually become the app your customers use. Run it before the last payment, and the question of ownership never becomes a dispute.

If you are commissioning an app, or taking one over from a previous developer, Linestech can advise on the repository, handover and verification arrangements that keep the code, keys and accounts firmly with your business.

Frequently asked questions

What is the difference between owning the app and owning the source code?

Owning the app usually means controlling the published product, the store listing and the user relationship. Owning the source code means holding the rights to and possession of the underlying code, so you can modify it, rebuild it or give it to another developer. You need both. An app you control but cannot modify becomes frozen the moment the original developer leaves.

Do I get the backend code too, or only the mobile app?

You should receive both, plus the admin dashboard, the database structure and the deployment configuration. State this explicitly in the contract, because "source code" is often interpreted narrowly as the mobile app project. The backend typically represents a large share of the engineering effort and is where your business data lives.

How do I check that the source code I received is complete?

Run a build test with an independent developer: they take only the repository, documentation and credentials you hold, and attempt to build the app and deploy the backend on a clean machine. If they can produce a working build and a running server, the handover is real. Any gaps they find should be closed before you release the final payment.

Can I read the code myself to check it?

You do not need to, and most business owners cannot. What you can check without technical skill: that commits are arriving regularly from named contributors, that the repository contains the app, backend and admin projects, and that the documentation exists. For a quality opinion, pay an independent developer for a short code review.

Is source code escrow necessary for a Nigerian SME?

Usually not, if you hold the repository yourself from the start, which achieves the same protection more directly. Escrow makes more sense when you have licensed a vendor's product rather than commissioned a custom build, or where the vendor retains ownership for commercial reasons. If you use it, ensure deposits are updated regularly and verified.

What if the developer used code from another project?

Reuse of generic components and a developer's own libraries is normal and usually permitted, but it should be disclosed. Ask for the third-party inventory and a warranty that everything is properly licensed and that nothing belonging to another client has been included. Custom work built specifically for you should be assigned to your business.

How should I store the keystore and credentials?

In a password manager or secure vault controlled by your business, with recovery access held by a director, plus an encrypted offline backup kept separately. Losing the signing key can prevent you from updating your published app, so treat it with the same care as banking credentials rather than leaving it in an email thread.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Apple Developer Program
• Google Play Console
• Node.js documentation
• PostgreSQL documentation
• GitHub documentation