Who Owns Custom Software Code? A Guide for Nigerian Businesses

Custom software is different from a website or a mobile app in one important way: it usually sits at the centre of how the business actually runs. An inventory system, a loan management platform, a hospital records system or a distributor portal holds years of operational data and encodes decisions nobody wrote down anywhere else. When ownership of that system is unclear, the business is not just risking a piece of software; it is risking the ability to keep trading on its own terms.

Ownership also gets more complicated with custom software because more parties touch the code: an agency, two contract developers, an in-house IT person, an offshore subcontractor nobody mentioned, plus open-source libraries and paid APIs. A contract that only says "the client owns the software" answers none of those questions properly. This guide explains what ownership covers, how it is normally handled, and how to convert ownership on paper into control in practice. It is not legal advice; have a Nigerian intellectual-property lawyer review any software contract of real value.

What does owning custom software actually mean?

Owning custom software means holding the copyright in the bespoke code, designs and documentation created for you, and holding administrative control of every place that code and its data live. The two must go together. A business that owns the copyright but cannot get into the repository or the cloud account owns a legal right it cannot exercise.

It is useful to separate four layers, because contracts usually address only the first:

• Legal ownership. Who holds copyright in the source code, database design, documentation, screen designs and internal tooling created specifically for the project.
• Practical control. Who holds the admin credentials for the code repository, the servers, the database, the domain, the CI/CD pipeline and the third-party API accounts.
• Right to modify and move. Whether you may change the software, hire a different firm to work on it, and take it elsewhere without permission.
• Continuity. What happens if the developer closes down, relocates, or simply stops responding.

A complete ownership position covers all four. In practice, most disputes in Nigerian software projects come from layers two and four, not layer one.

Who owns the code if the contract says nothing?

Under most copyright systems, including Nigeria's, the author of 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 contract developer or an agency is not your employee. So if nothing is written down, the firm that wrote the code may well own it, and you may hold only an implied licence to use the system for its intended purpose.

Nigeria's framework was updated by the Copyright Act 2022, and the treatment of commissioned works, employee-created works and the formalities for transferring rights are questions for a Nigerian intellectual-property lawyer to confirm for your specific arrangement. The commercial lesson does not depend on the fine detail: never rely on the default position. Put the transfer in writing before work begins, when you still have negotiating leverage.

Two traps are worth naming. First, "work made for hire" wording copied from an American template does not necessarily achieve the same result under Nigerian law; an express assignment is safer. Second, a paid invoice proves you bought a service, not that you acquired copyright. Businesses regularly produce a stack of receipts in a dispute and discover the receipts prove nothing about ownership.

Assignment, licence and escrow: three ways ownership is handled

There are three common commercial structures, and each is appropriate in different situations. The mistake is not choosing a licence; the mistake is thinking you have an assignment when you have a licence.

Source-code escrow is under-used in Nigeria and worth understanding. The developer deposits a current copy of the source code and build instructions with an independent third party, and if a defined event occurs, such as insolvency or abandonment of support, the code is released so another team can keep the system running. It is the right compromise when a vendor genuinely cannot assign ownership, for example where your system is a configured version of their own product. Escrow only works if the deposit is updated on a schedule, includes build and deployment instructions rather than just code, and has release triggers wide enough to cover prolonged non-performance, not only formal insolvency.

What you can own and what you never will

No modern software system is owned end to end by one party. Being realistic about that prevents a false sense of security.

The pragmatic target is not "we own 100% of every line". It is: we own all bespoke work, and we hold licences broad enough that any competent developer can take over without asking anyone's permission.

Ownership when several parties build the same system

This is where custom software diverges most from a simple website project. A business system built over three years can easily have four or five contributing parties, and each contributes a different ownership risk.

• Employees. Work created by an employee in the course of employment usually belongs to the employer, but job descriptions and employment contracts should still say so. If a staff developer built a critical internal tool at home in their own time, ownership becomes arguable.
• Independent contractors. The highest-risk category. A contractor engaged on a verbal agreement and paid by transfer owns what they wrote unless there is a written assignment. Every contractor needs the same IP clause the main vendor signs.
• Agencies. Usually have a standard contract. Read the IP section rather than assuming it favours you; many default to a licence.
• Subcontractors of your agency. Your contract must require the agency to hold assignments from everyone it engages, and to pass those rights through to you. Without this "flow-down" clause, your agency may be assigning rights it does not hold.
• Offshore or remote developers. Add a clause requiring written assignment governed by the same contract, plus confirmation of who physically holds the code.

A practical control: keep a simple contribution register listing every person or firm that has committed code, the dates, and the signed IP document covering them. It takes ten minutes a quarter and it is the document that resolves a dispute three years later.

Who owns the data, the database and the integrations?

Data ownership is often more valuable than code ownership and far more often neglected. A competitor could rebuild your software in six months; they cannot rebuild eight years of your transaction history. Insist that the contract states clearly:

1. All business data, customer data and derived data belong to your company, not the vendor.
2. The vendor will provide a complete export in an open, documented format (CSV, SQL dump, JSON) on request and at termination, at no additional charge.
3. The vendor will not use your data to train models, build benchmarks or create derivative products without written consent.
4. On termination, the vendor deletes retained copies within a stated period and confirms deletion in writing.
5. Processing of personal data complies with the Nigeria Data Protection Act 2023, with the vendor acting as processor under your instructions.

Integrations raise a parallel question. If your system connects to Paystack, Flutterwave, a bank API, a WhatsApp Business Platform account or an accounting package, those accounts belong in your company's name, with the developer granted access rather than owning it. Merchant accounts registered in a developer's name create settlement and compliance problems that are far harder to unwind than a code dispute.

Example (hypothetical): a distributor discovers the gap at renewal

Example (hypothetical). A fast-moving consumer goods distributor in Kano commissions a custom distribution management system: sales rep app, van stock reconciliation, credit limits, and a reporting dashboard. The build costs roughly ₦12,000,000 across eighteen months, paid in milestones, with an annual support retainer of about ₦1,800,000. The contract is four pages and says the vendor "grants the client the right to use the software".

Three years later the vendor proposes a support increase and a migration to their newer hosted product. The distributor asks for the source code so an alternative firm can quote. The vendor declines, correctly pointing to the contract; the cloud account, database and repository are all in the vendor's name. The realistic options are to accept the new terms or rebuild from scratch and re-enter three years of transaction history.

Nothing dishonest happened. The vendor delivered working software and the client paid for a licence without realising it. Three things at signature would have prevented all of it: an assignment clause covering bespoke code, cloud and repository accounts in the distributor's name with the vendor added as a collaborator, and a quarterly data-export obligation. Adding them at the start costs a few hours of legal review; fixing it afterwards costs a rebuild.

The ownership clauses to insist on in a software contract

Use this as a review list when a software proposal or contract lands on your desk. What Should Be Included in a Software Development Contract? on what should be included in a software development contract covers the wider agreement; this list is the ownership subset.

• Express assignment of all copyright and other IP in bespoke deliverables to your company, effective on full payment.
• Definition of deliverables that names source code, database schema, design files, documentation, build scripts and test suites.
• Retained-materials clause listing exactly what the vendor keeps, with a perpetual, irrevocable, royalty-free, transferable licence to you covering those parts.
• Flow-down clause requiring the vendor to obtain written assignments from all employees, contractors and subcontractors.
• Open-source disclosure: a list of libraries used and their licences, with a warranty that no component imposes obligations incompatible with your commercial use.
• Accounts and credentials clause: hosting, domain, repository, payment and API accounts are registered to your company from day one.
• Data ownership and export clause, including format, frequency and deletion on termination.
• Escrow clause where assignment is genuinely impossible, with update schedule and realistic release triggers.
• Further-assurance clause requiring the vendor to sign any additional documents needed to perfect the transfer.
• Exit and transition clause: a defined handover period, documentation standard and cooperation obligation, priced in advance.
• Non-assertion of moral rights, to the extent permitted by law.
• Survival: the ownership, data and confidentiality clauses survive termination.

What changes for Nigerian businesses

Several local realities make ownership more urgent, not less, for a Nigerian business buying custom software.

Vendor continuity is a live risk. Small development firms open and close, and key developers relocate. A contract that depends on one person's continued goodwill is fragile. Escrow, documentation standards and repository access matter more here than in markets with deeper vendor pools.

Informality is the norm at SME level. Many projects start on WhatsApp with a quotation and a deposit, so the ownership conversation never happens. Moving the ownership terms into a short written agreement, even a three-page one, is the highest-value hour in the whole project.

Enforcement is slow and expensive. Winning a Nigerian court case about software copyright is not a plan. Possession is the practical remedy: if the code is in your repository and the data is in your cloud account, you rarely need to litigate. Structure for possession first, legal rights second.

Foreign-currency dependencies. Cloud hosting, paid components and API usage are priced in dollars, and naira volatility moves those bills. If they sit on the vendor's card, you are exposed to the exchange rate and their markup, and you cannot switch providers without them. Own the billing accounts.

Regulatory obligations follow the data, not the code. Under the Nigeria Data Protection Act 2023, the business that determines how personal data is processed carries controller obligations regardless of who wrote the software. You cannot contract that away to your developer, so you need the access and export rights to discharge it. Verify current requirements with the Nigeria Data Protection Commission.

Turning ownership into control: the handover checklist

Ownership becomes real at handover. Do not accept "it is all working" as a completion statement. Require the following, and treat the final payment milestone as conditional on receiving it.

1. Repository access as owner or admin of the organisation account, with full commit history, not a zipped folder of files.
2. Build and deployment instructions that a new developer can follow to get a working environment from scratch, tested by someone who was not on the project.
3. Environment inventory: production, staging and any test environments, with URLs, sizes and costs.
4. Credential register: every server, database, API key, email service, payment account and third-party tool, with your company as the account owner.
5. Database schema documentation plus a current backup you have personally restored somewhere else at least once.
6. Open-source and third-party licence list, with renewal dates and who pays.
7. Design source files in their native format.
8. Architecture note: a one-page diagram of what talks to what, including scheduled jobs and integrations.
9. Known-issues list and the backlog of deferred work, in writing.
10. Signed IP assignment from the vendor and confirmation that assignments exist for all subcontractors.

A good test of your position: could a new developer, given only what you hold today, restore the system on fresh infrastructure within a week without contacting the original vendor? If the honest answer is no, you do not yet have control.

Mistakes to avoid

• Assuming payment equals ownership. It does not. This assumption causes more custom-software disputes than any technical failure.
• Accepting a zip file as handover. Source code without commit history, build instructions and environment configuration is often not buildable by anyone else.
• Letting the developer own the cloud and domain accounts. Convenient at the start, expensive later. Create the accounts yourself and invite the developer in.
• Signing a contract with no exit clause. Transition terms not priced at signature get priced during a dispute, when your leverage is lowest.
• Ignoring subcontractors. Your agency cannot assign rights it never acquired. Ask directly who else has written code.
• Treating escrow as a formality. A deposit made once in year one and never updated is worth almost nothing by year three.
• Forgetting the data. Businesses negotiate hard over code, then discover they have no export of the records that actually matter.
• Leaving documentation to the end. Tie it to payment milestones; otherwise it is the first thing dropped when the schedule slips.

Conclusion

Ownership of custom software code is a contract question, an accounts question and a documentation question at the same time. Get an express assignment of bespoke work, obtain a broad and irrevocable licence to anything the vendor retains, register every hosting, payment and repository account in your own company's name, and make complete documentation a condition of final payment. Where a vendor genuinely cannot assign, use a properly maintained escrow arrangement instead of hoping for goodwill.

The decision rule is simple. If the software is core to how your business runs, insist on full assignment and full control. If it is peripheral, a well-drafted licence with strong data-export rights may be enough. Silence is never enough, and silence is the default in most Nigerian software agreements. Fix it before the first line of code is written.

Planning a custom software build, or trying to work out what your current agreement actually gives you? Linestech builds business systems with source-code assignment, documented handovers and client-owned infrastructure as standard, and can review the ownership position of a system you already run. Send us your requirements and we will tell you honestly what you own and what you do not.

Frequently asked questions

Does paying in full automatically transfer software copyright to me?

No. Payment discharges your obligation under the contract; it does not transfer copyright by itself. Copyright moves only where the contract contains an express written assignment, or where the work was created by your employee in the course of employment. Many contracts sensibly make the assignment effective on full payment, which protects both sides, but the clause still has to exist.

Can a developer reuse code they wrote for my business with another client?

It depends on what was assigned. Bespoke code covered by an assignment cannot be reused without your permission. A vendor's own reusable framework, generic utilities and open-source components can be reused freely, and reasonably so. The contract should state explicitly which category each part falls into, so reuse does not become a surprise.

What is source-code escrow and do I need it?

Escrow means an independent third party holds a current copy of your source code and build instructions, releasing it to you if defined events occur, such as vendor insolvency or sustained failure to support. You need it when the vendor genuinely cannot assign ownership, typically where your system is a configured version of their product. If you can get a full assignment instead, take the assignment.

Who owns the code my in-house developer writes?

Normally your company, where the work is created by an employee in the course of employment. Strengthen that position by stating it in the employment contract, ensuring work happens in company repositories and on company accounts, and applying the same clause to anyone engaged on a consultancy basis, including staff who invoice rather than receive salary.

If I own the code, can any developer take over the system?

Legally yes, practically only if the handover was complete. Takeover depends on commit history, documentation, environment configuration and credentials. Plenty of businesses own code that no new developer will touch because nobody can build or deploy it. Insist on a documented, reproducible build as a delivery condition.

Does open-source software in my system limit my ownership?

It limits what you can claim to own, not your ability to use the system. Permissive licences such as MIT and Apache impose light obligations, usually attribution. Copyleft licences such as GPL can impose conditions if you distribute the software. Ask for a written component list with licences, and have it checked if you intend to resell or distribute the product.

What should I do if my current vendor already owns everything?

Start with a calm commercial conversation rather than a legal one. Many vendors will agree to an assignment, an escrow arrangement or account transfers in exchange for a renewed support agreement or a modest fee. Get the data export first, since that is usually the least contentious request and the most valuable asset. Escalate only if cooperation fails.

Should ownership be in the name of the company or the founder?

The registered company, in almost all cases. Assets held personally by a founder complicate investment, bank facilities, due diligence and succession. Ensure the entity named in the contract matches your Corporate Affairs Commission registration exactly, including the suffix.

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.

• Corporate Affairs Commission (CAC)
• Nigeria Data Protection Commission (NDPC)
• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers
• PostgreSQL documentation
• GitHub documentation