1. Home
  2. Blog
  3. Mobile App Development
  4. Who Owns the Code After App Development? A Guide for Nigerian Businesses

Who Owns the Code After App Development? A Guide for Nigerian Businesses

An African businesswoman at work in an office — an article about who owns the code after app development

This is one of the most common and most expensive misunderstandings in Nigerian app projects. A business pays ₦6,000,000 for a customer app, the relationship with the developer sours a year later, and the owner discovers that the repository, the cloud account and the Play Console listing are all in the developer's name. The app works, but the business does not control it.

The good news is that code ownership is straightforward to secure when it is addressed early. This guide explains what "ownership" actually covers, what the default legal position tends to be, which contract clauses matter, what you can and cannot own, and what to collect at handover so that ownership on paper becomes control in practice. It describes the issues in plain business language; it is not legal advice, and you should have a Nigerian lawyer review any contract of real value.

What does "owning the code" actually mean?

Owning the code means holding the intellectual-property rights (chiefly copyright) in the custom source code written for your app, together with practical control of the places where that code and its supporting services live. Legal ownership without practical control is close to worthless: you may own the copyright and still be locked out of the repository.

It helps to separate three layers:

  • Legal ownership: who holds the copyright in the code, designs, documentation and other original work created for the project.
  • Practical control: who holds the admin rights to the code repository, cloud hosting, databases, domain, app-store accounts and third-party API keys.
  • Right to use: whether you are permitted to run, modify, extend and hand the code to another developer, and on what conditions.

A complete ownership position covers all three. Many disputes arise because a contract addresses the first layer and nobody thinks about the second and third until the developer stops replying to WhatsApp messages.

Who owns the code by default if the contract is silent?

In most copyright systems, including Nigeria's, the general starting position is that the person who creates an original work is its first owner, unless the work was created by an employee in the course of employment or the rights have been transferred in writing. A freelance developer or an agency is not your employee. That means, absent a written assignment, the developer may well be the owner of what they wrote, and you may hold only an implied licence to use the app for the purpose it was built.

Nigeria's copyright framework was updated with the Copyright Act 2022, and the precise treatment of commissioned works, employee works and the formalities for transferring rights are matters a Nigerian intellectual-property lawyer should confirm for your specific situation. The practical lesson does not depend on the fine print: never rely on the default. Put the transfer in writing, in the contract, before work starts.

Two further points catch businesses out. "Work for hire" language is largely an American concept, and copying it from a US template does not guarantee the same effect in Nigeria; use an express assignment instead. And an invoice that says "app development" is not an assignment: it proves you paid for a service, not that you acquired the copyright.

Assignment vs licence: the clause that decides everything

The difference between an assignment and a licence is the difference between owning a house and renting it. An assignment transfers ownership of the copyright to you. A licence lets you use the code under conditions the owner sets, which can include time limits, restrictions on modification, or a ban on moving to another developer.

FeatureAssignment (you own it)Licence (you use it)
Copyright holder after paymentYour companyDeveloper or agency
Can you hire another developer to modify it?YesOnly if the licence allows
Can the developer reuse your custom code for others?Only if you permit itUsually yes
Can you sell the app or the company with its code?YesDepends on transferability
Typical wording"assigns all right, title and interest""grants a non-exclusive licence to use"
Usual triggerOn full paymentOn signing or payment

A well-drafted assignment clause will usually:

  1. State that all custom deliverables (source code, designs, documentation, database schemas, build scripts) are assigned to the client.
  2. Make the assignment effective on full payment of the agreed fees, which protects the developer from non-payment.
  3. Include a waiver or non-assertion of moral rights to the extent the law allows.
  4. Require the developer to sign any further documents needed to perfect the transfer.
  5. Carve out clearly what is not assigned (see the next section), so there is no ambiguity.

Some agencies prefer to retain ownership of their reusable internal frameworks and grant you a perpetual, irrevocable, royalty-free licence to those parts. That is a reasonable compromise provided the licence is broad enough that you can modify the app and move to another developer freely.

What you can own and what you cannot

Not every line of code in your app is capable of being assigned to you, and pretending otherwise creates a false sense of security. A realistic app is a mixture of the following.

ComponentCan you own it?Notes
Custom application code written for youYesThis is what the assignment clause should cover
UI designs, logos, copy, illustrationsYesInclude design files (Figma, source assets) in the deliverables
Open-source libraries and frameworksNoYou use them under their licence (MIT, Apache, GPL, etc.)
Developer's pre-existing tools and boilerplateUsually noNegotiate a perpetual licence to use and modify
Third-party SDKs (payments, maps, analytics)NoGoverned by the provider's terms, e.g. Paystack or Google
Platform code (Android, iOS, cloud services)NoYou never own the operating system or the cloud
No-code or low-code platform outputRarelyOften the app cannot leave the platform at all
Your business data and customer recordsYesShould be stated explicitly, with an export obligation

Most business apps are built on permissive open-source licences (MIT, Apache 2.0, BSD) that allow commercial use with little more than attribution. A few, notably the GPL family, can impose conditions on distribution. Ask for a list of third-party components and their licences as part of the handover documentation.

Ownership of accounts, credentials and data

The single most common way Nigerian businesses lose control of an app is not through copyright but through accounts. If the Apple Developer Program membership, the Google Play Console, the cloud hosting, the domain, the payment-gateway merchant account and the SMS or WhatsApp API accounts are all registered in the developer's name and email, then the developer controls the app regardless of what the contract says about copyright.

The rule is simple: every account that the app depends on should be created in the name of your company, with your company's email and payment method, and the developer should be added as a collaborator or team member with the access they need. When the project ends, you remove them. If it is too late and the accounts already exist under the developer's name, the contract should oblige them to transfer ownership, and you should complete the transfers before making the final payment.

Data is a separate issue. Your customer records, orders, transactions and analytics are your business's information, and under the Nigeria Data Protection Act 2023 you are the party accountable for how personal data is handled. The contract should state that all data belongs to you, that the developer acts only on your instructions when processing it, and that you can export it in a usable format at any time.

How ownership differs by engagement type

Who you hire changes the default risks, so it helps to know what to expect from each arrangement.

  • Freelance developer: often flexible about assignment, but frequently working from personal accounts and a personal laptop. The risk is practical: code that lives only on one person's machine. Insist on a repository under your organisation from day one.
  • Nigerian agency or studio: usually has a standard contract. Some assign everything; some assign the custom code but keep their framework under licence; a few grant only a licence and charge more for assignment. All three are negotiable.
  • Offshore agency: contracts are often governed by foreign law, which complicates enforcement from Nigeria. Prefer Nigerian governing law and insist on assignment plus full account control so you rarely need to enforce anything.
  • No-code or low-code platform: you typically own your content and data but not the application, and you may not be able to export working code at all. Acceptable for a prototype, dangerous for a core business system.
  • In-house employee: work created in the course of employment generally belongs to the employer, but the employment contract should say so expressly.
  • Equity or revenue-share developer: ownership is often left vague. Treat it like a paid engagement: written assignment to the company, not the founder personally, plus a clear vesting or buy-out arrangement.

Example (hypothetical): a Lagos logistics company discovers it owns nothing

Example (hypothetical): a dispatch and haulage company in Lagos pays a freelance developer ₦4,500,000 across six months to build a driver app and a customer tracking app. The apps go live and work well. Eighteen months later the company wants to add Paystack payments and a corporate-client portal, but the original developer has relocated and stopped responding.

When a new agency reviews the situation, the picture is bleak:

  • The code is in a private GitHub account belonging to the freelancer.
  • The backend runs on a cloud account registered to the freelancer's personal email and card.
  • The Google Play listing is under the freelancer's developer account; the Apple app was published under an individual membership.
  • The only contract is a two-page proposal with no IP clause.

The company's options are all costly: track down the freelancer and negotiate a transfer (with no leverage), or rebuild from scratch at a higher price than the original build. Had the proposal included a one-paragraph assignment clause and had the accounts been created under the company's name, the new agency could have taken over within days.

The lesson is that ownership is cheap to secure at the start and expensive to recover later.

The code ownership checklist for your contract

Use this checklist when reviewing any app development agreement. Each item addresses a specific way ownership goes wrong.

  • An express assignment of all custom code, designs and documentation to your company (not to you personally, unless you intend that).
  • The assignment takes effect on final payment, with a clear statement of what "final payment" means.
  • Any retained developer frameworks are licensed to you perpetually, irrevocably and with the right to modify and to transfer to another developer.
  • A list of third-party and open-source components with their licences, delivered at handover.
  • All accounts (app stores, cloud, domain, payment gateway, messaging APIs) to be created in your company's name or transferred to it before final payment.
  • Data belongs to you; the developer processes it only on your instructions; you can export it at any time.
  • Confidentiality obligations that survive the end of the contract.
  • A cooperation obligation: the developer will sign further documents and provide reasonable handover assistance.
  • Nigerian governing law and a dispute resolution clause you can realistically use.
  • Clarity on whether the developer may showcase the app in their portfolio (fine to allow, but say so).

For the broader contract structure, including payment milestones, acceptance testing and warranties, see the companion article on what should be included in an app development contract.

What to collect at handover

Ownership on paper is confirmed by what you physically hold at the end of the project. Before releasing the last payment, verify that you have:

  1. Repository access as owner for every codebase: mobile app(s), backend, admin dashboard. Your organisation should own the repository; the developer should be a collaborator you can remove.
  2. Signing keys and certificates: the Android upload key or keystore and passwords; the Apple distribution certificates and provisioning profiles, or the ability to regenerate them from your own Apple account.
  3. Environment configuration: all environment variables, API keys and secrets, stored in a password manager your company controls.
  4. Cloud and hosting admin: root or owner access to the cloud provider, database, storage buckets and any managed services.
  5. Domain and DNS control for any web components or API endpoints.
  6. App-store ownership: the Play Console and App Store Connect accounts in your name, with the developer as a team member.
  7. Design source files and brand assets in editable formats.
  8. Documentation: how to build the app from source, how to deploy the backend, the architecture overview and the list of third-party services with their billing arrangements.
  9. A working build test: ideally your team, or an independent developer, builds and deploys the app from the handed-over materials once, to prove they are complete.

If any of these are missing, ownership is incomplete regardless of the contract.

What changes for Nigerian businesses

The ownership principles are universal, but several Nigerian realities change how much they matter and how to handle them.

  • Informal contracting is common. Many app projects begin as WhatsApp conversations and a bank transfer. That informality is exactly why disputes over ownership are frequent. A short written agreement with an IP clause is worth more than a long proposal without one.
  • Developer mobility is high. Talented Nigerian developers frequently relocate abroad or move into full-time roles. Your project must survive the developer's departure, which means ownership and documentation are not optional.
  • USD-priced services are often paid from personal cards. Cloud hosting, Apple membership and AI APIs are billed in dollars, and developers sometimes pay from their own dollar cards for convenience. That leaves the account in their name. Use a company dollar card or virtual card, or reimburse rather than let the developer own the account.
  • Enforcement is slow and expensive. Litigation in Nigerian courts takes time. The aim is to structure the deal so that you never need to enforce, primarily through account control and payment timing.
  • NDPA 2023 accountability. Your company is accountable for customer data even if a developer built and hosts the system. Ownership of data and the ability to move it are compliance issues, not only commercial ones.
  • Registered companies own more cleanly. Assigning IP to a CAC-registered company rather than to a founder personally simplifies investment, partnerships and eventual sale.

Mistakes to avoid

  • Assuming payment equals ownership. It does not. Only a written transfer does, and the reason is that copyright arises automatically in favour of the creator.
  • Accepting "licence" wording without noticing. A perpetual licence can be acceptable, but only if it allows modification and transfer to another developer. A restricted licence turns you into a tenant.
  • Letting the developer create the accounts. Convenience during the build becomes a hostage situation at the end. Create accounts yourself and grant access.
  • Paying the final instalment before handover is verified. Final payment is your only leverage. Tie it to a completed handover checklist.
  • Ignoring the backend. Owners sometimes secure the mobile app code but forget the server, database and admin panel that make it work.
  • Not asking about open-source licences. A rare but real problem if a component with restrictive terms is bundled into a commercial app.
  • Storing secrets in one person's head. Keystore passwords and API keys must be in a company-controlled vault, not a developer's notes app.
  • Failing to update the contract when scope grows. Phase two features built under a WhatsApp agreement are not covered by the phase one assignment unless the contract says future work is included.

Conclusion

Who owns the code after app development is decided by two things: what the contract says and who controls the accounts. A written assignment clause, effective on final payment, gives you legal ownership of the custom code and designs. Company-owned accounts for the repository, cloud, app stores, domain and payment gateway give you practical control. Together with a handover checklist tied to the final instalment, they turn a paid-for app into a genuine business asset that survives any change of developer.

If you are scoping an app and want the ownership, handover and documentation arrangements built into the project from the start, Linestech can walk you through how a clean engagement is structured before you commit to a build.

Frequently asked questions

Can I get ownership of the code after the project has already finished?

Yes, if the developer agrees. You would sign a short deed or agreement of assignment transferring the copyright, usually for a nominal or negotiated fee, and then complete the account transfers. The challenge is leverage: once you have paid in full, the developer has little incentive to co-operate. A polite, prompt request while the relationship is still good is your best route.

Does the developer have to hand over the source code, or only the app?

Only if the contract says so. Delivering a working app on the stores is not the same as delivering source code, and a developer who owns the code can legitimately decline to hand it over. Your agreement should list source code, build instructions and design files as deliverables, and the assignment clause should cover them.

Can the developer reuse parts of my app for other clients?

If they retained ownership, generally yes. If they assigned the custom code to you, they cannot reuse that specific code without permission, though they remain free to use general skills, techniques and their own pre-existing frameworks. You can also add a clause preventing them from building a directly competing product for a period, but keep such restrictions reasonable.

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

Copyright protects the expression, meaning the actual code and designs, not the underlying idea. Owning the code does not stop a competitor from building a similar app independently. Protecting the idea itself relies on confidentiality, speed to market, trademarks for the brand and, occasionally, patents, which are rarely practical for ordinary business apps. See the related article on protecting your app idea in Nigeria.

What if my app was built on a no-code platform?

You typically own your content, configuration and data but not the application itself, which exists only inside the platform. You cannot usually take the "code" elsewhere. That is fine for prototypes and internal tools, but for a customer-facing product you intend to grow, plan to migrate to custom code at some point and ensure you can export your data.

Should the assignment be to me personally or to my company?

To the company, in almost every case. Investors, partners and buyers will expect the company to own its core technology. If the company is not yet registered with the CAC, assign to yourself and then assign to the company once it exists, with your lawyer's guidance on the paperwork.

Is a signed contract really necessary, or is email confirmation enough?

A written record of the agreement is what matters, and email can form part of that record. However, an assignment of copyright is the kind of transfer that should be in a clearly signed document. A one-page IP assignment attached to the proposal is the simplest reliable approach. Ask a Nigerian lawyer to confirm the formalities for your situation.

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.