Technology Agreements in Nigeria: How to Protect Software and IP When Hiring Developers
Technology Agreements in Nigeria: How to Protect Your Software and IP When Hiring Developers
Hiring a developer to build an app, website, SaaS platform, fintech product, marketplace, internal system or artificial-intelligence tool can feel simple: agree on the price, explain what you want, pay the developer and wait for the finished product.
The difficult question usually appears later: Who actually controls what was created?
Why this article exists: the missing question behind “Who owns my app?”
A search for a software development agreement usually produces a familiar list: define the project, agree on payment, add confidentiality, include an intellectual-property clause, add termination terms and choose a dispute-resolution mechanism.
Those points are useful, but they can create a dangerous illusion of completeness. A founder can copy a sophisticated-looking IP clause into a contract and still have a weak ownership position because the agreement never identifies the code that is actually being transferred, never identifies the developer's pre-existing libraries, never regulates subcontractors, never controls the repository, never addresses third-party licences and never explains what happens when the developer stops working.
That is the gap this Daily Reality NG guide is designed to address.
The central idea is simple: software ownership is not a sentence; it is a control chain.
International IP guidance makes the same broader point. WIPO's 2026 guidance on software development agreements stresses that a venture should identify source-code ownership, updates, related IP, background IP, usage rights, open-source components, confidentiality, warranties, termination and handover.
Daily Reality NG takes that concept further for the Nigerian business owner by asking a more practical question:
If the answer is no, you may have paid for software without building enough legal and operational control around it.
The real problem is not the contract—it is control
Consider two founders who each spend ₦5 million developing a software platform.
Founder A has a signed agreement, but the developer owns the GitHub organisation, the cloud account, the domain, the deployment credentials and several private libraries. The agreement says the client owns “all software developed under the project,” but there is no schedule listing excluded background technology and no procedure for transferring third-party licences.
Founder B has a similarly priced project, but the company owns the repository, the domain, the cloud account and the production credentials. The contract defines project deliverables, foreground IP, background IP, open-source disclosures, source-code delivery, documentation, acceptance, security obligations and termination handover.
Both founders may have paid the same amount. Their control positions, however, are completely different.
| Control area | Weak arrangement | Strong arrangement |
|---|---|---|
| Copyright | “Client owns the software.” | Identified deliverables, ownership mechanism and written IP provisions. |
| Source code | Developer keeps the only repository. | Company-controlled repository with regular backups. |
| Background IP | Not mentioned. | Listed or defined with the client's licence rights. |
| Third-party code | Developer chooses libraries without disclosure. | Components and licence obligations are disclosed and governed. |
| Data | Developer has unrestricted production access. | Access is limited, logged and contractually controlled. |
| Exit | “Return all materials.” | Specific code, documentation, credentials, infrastructure and handover checklist. |
This distinction is particularly important for startups. A technology asset can become one of the most valuable things a company owns, yet its ownership may be spread across code, documentation, databases, designs, trademarks, deployment infrastructure, credentials, cloud services and confidential know-how.
Therefore, the objective of a technology agreement should not be merely to “protect the code.” It should establish legal ownership, practical access, commercial freedom and operational continuity.
What Nigerian copyright law actually changes
Nigeria's current copyright framework is the Copyright Act 2022. The Nigerian Copyright Commission publishes the Act through its official website.
The Act is important because computer programmes fall within the statutory framework for literary works. That gives software an important copyright foundation, but copyright does not solve every technology-ownership question.
One of the most important distinctions is between expression and ideas or methods. Copyright protects qualifying expression; it does not turn every business concept, procedure, process, method of operation or abstract idea into a copyright monopoly.
That means a founder should not assume that “my business idea belongs to me” is equivalent to saying “I own the software implementation.” Those are different questions.
Section 28: the starting point matters
Section 28 of the Copyright Act addresses initial ownership and recognises that ownership can be affected by agreement. The Act also contains specific rules concerning works created in employment.
The crucial practical lesson is not to rely on a vague assumption that “the person paying owns everything.”
An independent developer relationship should be documented deliberately rather than treated as though it were automatically identical to an employer-employee relationship.
Section 30: assignment is a separate legal mechanism
Section 30 deals with transfer of copyright. The Act allows copyright to be transferred by assignment and permits limitations to be placed on an assignment. Importantly, an assignment or exclusive licence has no effect unless it is in writing.
This is one reason an IP clause buried in an informal WhatsApp conversation is a poor substitute for a properly executed development agreement.
It is also why founders should distinguish among three different concepts:
- Ownership: who holds the relevant rights?
- Licence: who is permitted to use the rights, and under what conditions?
- Access/control: who physically controls the code, systems, accounts and credentials?
They overlap, but they are not the same.
Do not promise yourself “everything forever” without checking the wording
Another overlooked point is that the Act contains restrictions concerning assignments of future works. A contract should therefore be drafted around identifiable project work and commercially sensible rights rather than using careless language purporting to transfer every creative work a developer might create for the rest of their career.
This is one area where professional legal drafting matters. A broad clause can look powerful while creating uncertainty about what was actually transferred.
What copyright does not automatically give you
Copyright ownership does not automatically give a company:
- the developer's private GitHub account;
- the developer's cloud account;
- a third-party API licence;
- ownership of an open-source library;
- exclusive rights to a generic development framework;
- the developer's pre-existing tools;
- control over a domain registered personally by the developer;
- ownership of customer personal data simply because the developer processed it;
- rights to a third party's trademark; or
- permission to use every component embedded in the product.
That is why a technology agreement needs to operate across multiple layers.
Why “work-for-hire” can mislead Nigerian founders
“Work for hire” is a familiar expression in international software contracting. It should not be used as a magic phrase that supposedly answers every Nigerian IP question.
Different jurisdictions structure commissioned works differently. Even WIPO's global software guidance presents assignment, licensing, work-for-hire and joint ownership as different contractual models rather than assuming that one phrase works everywhere.
For a Nigerian founder, the safer question is:
If the commercial objective is outright ownership of project-created copyright, the agreement should say so clearly and use the appropriate assignment mechanism. If the developer is retaining ownership, the contract should instead define the licence with enough breadth to support the company's actual business model.
Calling something “work for hire” without understanding the underlying Nigerian rights structure can produce false confidence.
The Daily Reality NG IP Control Chain
The most useful way to audit a software development agreement is to stop reading it as a collection of clauses and instead follow the life of the technology.
Daily Reality NG recommends this eleven-link control chain:
If one link is missing, the chain can break.
For example, you may own the copyright but still have no practical access because the only deployment account is controlled by the developer. Or you may control the repository but discover that the most important authentication component is licensed from another company and cannot be transferred.
The control chain therefore gives founders a better audit question than “Did my lawyer include an IP clause?”
The better question is: “Can I trace ownership and operational control from creation to exit?”
Four ways to structure software ownership
There is no universal requirement that every developer must surrender every piece of technology they have ever created. The commercially correct arrangement depends on the project.
| Model | Developer | Client | Best suited to | Main risk |
|---|---|---|---|---|
| Assignment | Transfers agreed project IP. | Owns assigned rights. | Custom startup product, proprietary platform, acquisition-focused company. | Background/third-party IP may be accidentally swept in. |
| Licence | Retains ownership. | Receives defined usage rights. | Reusable developer platforms, agency frameworks. | Licence may restrict resale, modification or transfer. |
| Joint ownership | Shares agreed rights. | Shares agreed rights. | Genuine collaborative ventures. | Future exploitation becomes complicated without detailed rules. |
| Hybrid | Retains background technology. | Owns project-specific foreground IP plus licences to embedded background components. | Most sophisticated agency/contractor projects. | Requires careful schedules and definitions. |
WIPO distinguishes assignment from licensing in essentially the same commercial way: assignment transfers ownership, while licensing gives permission to use an IP asset while ownership remains with the licensor.
Why the hybrid model is often more realistic
Imagine an experienced Nigerian development agency has built its own authentication framework, deployment scripts, UI components and internal testing tools over several years. It agrees to build a fintech platform for a client.
It would be commercially unreasonable for the client to claim ownership of every pre-existing tool the agency has ever created.
But the client may reasonably require ownership of the custom application code, custom business logic, bespoke documentation and project-specific designs created specifically for the engagement.
The solution is not “client owns everything.” It is to identify foreground IP and background IP, then define the licence necessary for the client to use the embedded background material.
Foreground IP versus background IP: the clause many founders misunderstand
Think of a developer entering your project carrying a toolbox.
The toolbox may contain technology created before your project. Your project may produce new tools and code. If the contract does not distinguish the two, an argument can arise over where one ends and the other begins.
Foreground IP
Foreground IP generally means IP created during the project as a result of the engagement. Depending on the contract, this can include:
- custom source code;
- custom object code;
- project-specific documentation;
- custom database structures;
- custom interface assets;
- test scripts;
- technical specifications;
- bespoke automation scripts;
- project-specific configuration;
- custom architecture documentation; and
- other copyrightable materials created specifically for the project.
Background IP
Background IP can include technology the developer already owned before the engagement, reusable frameworks, generic utilities, development methodologies and other pre-existing materials.
WIPO specifically recommends distinguishing background IP from foreground IP in collaborative technology arrangements.
The practical test
Ask the developer to produce a Background IP Schedule.
If the developer says there is no background IP, that should not automatically end the discussion. Ask what frameworks, libraries, templates, internal tools and reusable components will be used.
| Asset | Created before project? | Created specifically for project? | Recommended treatment |
|---|---|---|---|
| Developer's existing deployment framework | Yes | No | Background IP + suitable licence. |
| Custom customer portal | No | Yes | Project IP; ownership/licence expressly defined. |
| Open-source database library | No/third party | No | Third-party/open-source licence analysis. |
| Custom API integration code | No | Yes | Project IP subject to contract. |
| Developer's generic testing utility | Yes | No | Background IP or licence. |
Source-code ownership is not the same as having a copy
This is one of the most important practical distinctions in software contracting.
A founder may receive a ZIP file containing source code and still have weak operational control.
Ask:
- Who owns the repository?
- Who has administrator privileges?
- Who owns the domain?
- Who controls DNS?
- Who controls the cloud account?
- Who controls the CI/CD pipeline?
- Who controls deployment secrets?
- Who owns the package registry account?
- Who controls production databases?
- Who can revoke the developer's access?
- Are there independent backups?
WIPO's own software arrangements illustrate why source-code custody and ownership should be treated separately: source-code transfer can be governed independently from ownership and usage rights.
A stronger arrangement is for the business to own or control the principal accounts from the beginning, with the developer receiving the permissions needed to work.
Do you need a developer NDA in Nigeria?
An NDA can be useful, but an NDA is not a substitute for an IP assignment.
An NDA primarily governs confidential information: what is confidential, who can access it, how it can be used, when it can be disclosed and what happens after the relationship ends.
WIPO describes confidentiality agreements as instruments that define confidential information, access and permitted use, and recommends clear obligations and reasonable duration.
Your developer NDA or confidentiality clause should consider:
- source code;
- passwords and credentials;
- API keys;
- customer information;
- pricing;
- business plans;
- product roadmaps;
- security architecture;
- undisclosed vulnerabilities;
- financial information;
- technical documentation; and
- non-public product concepts.
The contract should also say what is not confidential, such as information already lawfully public or independently developed without use of the client's confidential information, subject to proper legal drafting.
Most importantly, confidentiality should continue after the developer leaves where the nature of the information justifies continuing protection.
Third-party and open-source software: the ownership trap
“We own the source code” becomes much less meaningful when the source code contains thousands of lines or packages created by other people.
Modern software is rarely created entirely from scratch. Developers commonly use frameworks, libraries, SDKs, fonts, icons, APIs, payment integrations, cloud services and open-source components.
WIPO specifically warns that software projects may contain third-party and open-source components whose licences affect what the client can do with the finished product.
The contract should require disclosure
Consider requiring the developer to provide a component register containing:
| Component | Provider | Licence | Version | Purpose | Commercial restriction? |
|---|---|---|---|---|---|
| Library/framework | Named provider | Exact licence | Version | Function | Yes/No + explanation |
Do not accept “everything is open source” as sufficient disclosure. Open source is not one licence with one set of obligations.
A project can contain permissive components and components with materially different obligations. The commercial question is not simply whether code is free to obtain. It is whether your company has the permissions it needs for its intended use.
Ask the developer five questions
- What third-party software is included?
- Which licences apply?
- Does any component impose source-disclosure or distribution obligations?
- Are any commercial licences required?
- Who will monitor licence changes and vulnerabilities after launch?
GitHub, GitLab, hosting and credential control
Your technology agreement should treat operational accounts as business assets, not personal conveniences.
Ideally, the client should establish the principal organisational accounts and invite the developer into them. This reduces the risk of a developer becoming a permanent gatekeeper.
The agreement should address:
- repository ownership;
- administrator rights;
- branch protection;
- backup procedures;
- deployment credentials;
- cloud infrastructure;
- domain registration;
- DNS;
- SSL certificates;
- CI/CD systems;
- package registries;
- monitoring tools;
- error-reporting platforms;
- analytics accounts; and
- payment-provider integrations.
A strong contract should also prohibit the developer from intentionally withholding access or creating a technical dependency that prevents the client from appointing another developer.
When the developer can see customer data, the contract becomes a data-governance document too
Software developers may need access to customer names, phone numbers, email addresses, payment-related information, user activity, identity information or other personal data.
Once that happens, the technology agreement cannot be treated purely as an IP document.
The Nigeria Data Protection Commission's guidance emphasises the importance of contractual arrangements between organisations and processors and addresses matters such as responsibilities, security measures, confidentiality, risk management and other processor obligations.
The agreement should therefore identify:
- what data the developer can access;
- why access is necessary;
- how access is authorised;
- where data may be stored;
- security requirements;
- confidentiality;
- subcontractor access;
- incident reporting;
- return or deletion requirements;
- access revocation after termination; and
- any additional data-protection documentation required for the relationship.
Do not give a developer a production database merely because it is technically convenient.
If anonymised or test data can perform the same development function, that can materially reduce risk.
Scope, specifications and acceptance: IP protection starts before the IP clause
A surprising number of IP disputes are really scope disputes wearing an IP costume.
The client says, “You were supposed to build this.” The developer says, “That feature was not included.”
The disagreement then affects payment, ownership, delivery and the ability to launch.
Your statement of work should therefore identify:
- features;
- platforms;
- technical architecture where necessary;
- integrations;
- security requirements;
- performance requirements;
- documentation;
- testing;
- deployment;
- source-code delivery;
- training;
- acceptance criteria; and
- post-launch support.
Acceptance should be measurable
“Software works properly” is too vague for a serious commercial agreement.
A better acceptance process could state that the client has a defined number of business days to test a milestone against agreed criteria and identify material defects. The developer then receives a defined correction period.
This protects both sides. The client does not have an unlimited ability to reject completed work, and the developer does not get to declare completion while material requirements remain unfinished.
Payment and ownership timing: do not leave the trigger ambiguous
Many development contracts say ownership transfers “upon payment” without defining what payment means.
Is it:
- payment of the relevant milestone?
- payment of the entire project fee?
- payment less disputed amounts?
- payment including approved change requests?
- payment after acceptance?
These details can become important if a project stops halfway through.
Suppose a developer receives 60% of a ₦10 million project fee and produces 70% of the code. The company terminates the project after a serious dispute.
If the agreement says nothing clear about ownership of paid-for work, delivery of incomplete work and rights following termination, both parties can enter a dispute over what the client may continue using.
A sophisticated agreement should therefore connect payment, acceptance, ownership, licence rights and termination rather than treating them as unrelated clauses.
Subcontractors: know who actually writes your code
You may contract with a Nigerian development agency while an individual developer in another country actually writes important portions of the code.
That creates a chain-of-title question.
Your agreement should require the principal developer or agency to ensure that employees, subcontractors and other contributors are bound by obligations sufficient to give the client the rights promised in the main agreement.
Ask for:
- the identity or role of material subcontractors;
- confirmation that they are contractually bound;
- IP assignment or equivalent rights flow-down;
- confidentiality obligations;
- security requirements;
- data-protection obligations where relevant; and
- restrictions on unauthorised subcontracting.
WIPO's software contracting materials specifically highlight the importance of determining whether developers are employees or contractors and the need for appropriate assignment arrangements where independent contractors create software.
Warranties, indemnities and infringement risk
An IP assignment answers who owns the rights. It does not automatically answer what happens if the delivered software infringes someone else's rights.
A carefully negotiated agreement may include representations or warranties concerning:
- authority to enter the agreement;
- right to provide the deliverables;
- disclosure of third-party components;
- compliance with agreed specifications;
- absence of intentionally malicious code;
- confidentiality;
- security obligations;
- third-party IP infringement; and
- compliance with agreed licensing requirements.
An indemnity is different from a warranty. It allocates financial consequences for specified losses or claims. Its scope, exclusions, caps and procedures require careful drafting.
Maintenance, updates and future development
Software ownership becomes more complicated after launch because software is never truly finished.
Bugs are fixed. Dependencies are updated. Security patches are applied. Features are added. APIs change. Servers are migrated.
Your agreement should therefore distinguish:
- the original development;
- bug fixing during the warranty period;
- maintenance services;
- new feature development;
- third-party service changes; and
- emergency support.
Otherwise, a developer may argue that every future modification is a new paid project, while the client may assume that all future changes are automatically included.
Define the commercial boundary.
Termination and the developer-exit problem
Founders often negotiate what happens when everything goes well and almost nothing about what happens when the relationship fails.
That is backwards.
The exit procedure should be designed when both parties are cooperating.
A proper handover should identify actual objects
- source-code repository;
- commit history;
- deployment scripts;
- database schema;
- technical documentation;
- architecture diagrams;
- environment variables and secrets, transferred securely;
- cloud resources;
- domain and DNS access;
- third-party service accounts;
- build instructions;
- testing instructions;
- known defects;
- open tickets;
- licence inventory;
- backup information; and
- administrator access.
WIPO's 2026 software agreement guidance specifically recommends planning termination and ensuring access to source code, documentation and passwords.
The developer replacement test
Here is an original Daily Reality NG test you can perform before signing:
If the answer is no, identify the missing dependency and fix it before launch.
The investor due-diligence test: could you prove your technology belongs to the company?
Founders sometimes think IP ownership matters only when there is a dispute.
That is too narrow.
A serious investor, acquiring company, strategic partner or lender may want evidence that the company has rights to the technology that supposedly creates its value.
Imagine your company says:
The next question may be:
If the answer is a WhatsApp chat, a payment receipt and a ZIP file from a developer, the commercial story becomes weaker.
WIPO specifically links clear IP ownership and traceability with commercialisation and due diligence.
Your virtual data room should eventually contain
- development agreements;
- IP assignments;
- employment IP clauses;
- contractor agreements;
- background-IP schedules;
- third-party licence records;
- open-source inventory;
- repository ownership information;
- domain records;
- trademark records where relevant;
- software documentation;
- data-protection agreements;
- material security documentation; and
- termination/handover records.
Nigerian scenarios: what the contract should have prevented
Scenario 1: The ₦3 million app that cannot be sold
A founder pays ₦3 million for a marketplace app. The developer delivers the application and the founder begins operating it.
Two years later, an investor asks whether the startup owns the source code.
The founder discovers that the agreement merely says the developer will “build an app for the client.” There is no clear assignment and no schedule of third-party components.
Lesson: Payment and possession are not enough. The ownership mechanism should have been addressed before development began.
Scenario 2: The developer owns the GitHub organisation
A SaaS company owns its custom code but the repository is controlled by the developer's personal account.
The developer stops responding during a commercial dispute.
The company may have legal arguments about ownership, but its immediate operational problem remains: it cannot deploy a new version.
Lesson: legal ownership without operational access can still create business paralysis.
Scenario 3: The “free” open-source component
A developer adds a component without documenting its licence.
The startup later wants to commercialise or redistribute the product in a way that requires rights it never analysed.
Lesson: “free to download” is not the same as “free of obligations.”
Scenario 4: The developer has production customer data
A contractor receives unrestricted access to the live customer database because it makes debugging easier.
The contract contains a generic confidentiality paragraph but no meaningful access controls or processor arrangements.
Lesson: the development contract should address data governance, not just intellectual property.
Scenario 5: The agency used its own framework
A development agency builds a custom logistics platform using an internal framework it already owned.
The client demands ownership of “all code.”
The agency refuses because that would transfer technology it uses for other clients.
Better solution: define the custom foreground work, identify the framework as background IP and grant the client the rights necessary to operate and commercially exploit the finished product.
The Daily Reality NG 100-point technology-contract risk score
Use this scoring system as a diagnostic tool. It is not a legal validity test; it is a business-control test.
| Category | Maximum | What earns a high score? |
|---|---|---|
| Project definition | 10 | Detailed scope and deliverables. |
| IP ownership | 15 | Clear ownership/assignment or licence structure. |
| Background IP | 10 | Identified exclusions and usable licence. |
| Third-party/open source | 10 | Component register and licence controls. |
| Repository/account control | 10 | Company-controlled accounts and backups. |
| Confidentiality | 10 | Specific information and post-exit obligations. |
| Data protection | 10 | Access controls and appropriate processor terms. |
| Acceptance/payment | 5 | Measurable milestones and clear triggers. |
| Subcontractors | 5 | Rights and obligations flow down. |
| Termination/handover | 10 | Detailed exit checklist. |
| Dispute/risk allocation | 5 | Commercially workable dispute and liability provisions. |
85–100: Strong control position. Continue improving project-specific weaknesses.
70–84: Moderate risk. The agreement may work, but important control gaps remain.
Below 70: High risk. Do not assume payment or possession solves the gaps.
The value of the score is not the number itself. Its purpose is to expose missing controls before a dispute exposes them for you.
Technology agreement clause matrix
| Clause | Question it must answer | Warning sign |
|---|---|---|
| Parties | Who is legally contracting? | Founder personally signs when the company is supposed to own the IP. |
| Scope | What is being built? | “Build an app” with no specification. |
| IP | Who owns project-created rights? | “Client owns everything” without defined mechanism. |
| Background IP | What does developer retain? | No schedule. |
| Third-party code | What belongs to someone else? | No component disclosure. |
| Confidentiality | What may the developer use or disclose? | One generic sentence. |
| Data | How is personal data handled? | Unlimited production access. |
| Repository | Who controls the code? | Developer's personal account. |
| Acceptance | When is work complete? | Subjective acceptance. |
| Payment | What triggers payment and ownership? | “Upon payment” without definition. |
| Termination | What happens when the relationship ends? | “Return all materials” only. |
| Subcontracting | Who else can access the project? | Unlimited delegation. |
Which ownership model should you choose?
If yes, investigate an ownership/assignment structure rather than assuming a narrow licence is sufficient.
If yes, consider a hybrid structure: client ownership of agreed project IP plus an appropriate licence to embedded background IP.
If yes, licensing may be more commercially sensible than forcing an assignment.
If yes, obtain specific legal advice about ownership, licensing and commercialisation rather than casually choosing joint ownership.
Joint ownership sounds fair but can become complicated because future licensing, modification, sale, enforcement and commercial exploitation may require additional rules.
Pre-signing technology agreement checklist
Before the first serious development milestone, check every item below:
- ☐ Correct legal names of client and developer are identified.
- ☐ The developer's capacity and authority to contract are clear.
- ☐ Project scope is attached or sufficiently described.
- ☐ Deliverables are measurable.
- ☐ Source-code ownership is expressly addressed.
- ☐ Copyright assignment/licensing mechanism is professionally drafted.
- ☐ Foreground IP is defined.
- ☐ Background IP is defined.
- ☐ Third-party components must be disclosed.
- ☐ Open-source licences are recorded.
- ☐ Repository ownership is established.
- ☐ Production accounts are controlled by the company.
- ☐ Developer access is role-based where practical.
- ☐ Confidentiality obligations are clear.
- ☐ Personal-data processing is addressed where applicable.
- ☐ Subcontracting is controlled.
- ☐ Acceptance criteria exist.
- ☐ Payment milestones are clear.
- ☐ Ownership timing is clear.
- ☐ Warranty and bug-fix obligations are clear.
- ☐ IP infringement risk is allocated.
- ☐ Maintenance is separated from new development.
- ☐ Termination rights are clear.
- ☐ Handover obligations are specific.
- ☐ Backup requirements exist.
- ☐ Post-termination access removal is addressed.
- ☐ Dispute-resolution terms have been reviewed.
- ☐ Governing-law provisions fit the transaction.
- ☐ The company has retained appropriate legal advice where the stakes justify it.
What to do if you already hired the developer without an IP agreement
Do not panic, and do not assume the situation is hopeless.
First create an inventory.
| Asset | Current controller | Evidence of ownership | Action needed |
|---|---|---|---|
| Source code | Developer/client | Repository records | Confirm rights and control. |
| Domain | Developer/client | Registrar record | Move to company control if necessary. |
| Cloud | Developer/client | Provider account | Establish organisational ownership. |
| Database | Developer/client | Hosting account | Secure access and backup. |
| Designs | Designer/client | Source files | Confirm IP rights. |
| Third-party software | Various | Licence records | Build component register. |
Then ask the developer to regularise the relationship through an appropriate agreement or assignment. Do not backdate documents or fabricate historical arrangements.
If the developer refuses, obtain legal advice before making threats or attempting technical self-help. The objective is to establish your actual rights and negotiate from evidence.
Your first 24-hour action plan
If you currently have a developer working without a proper technology agreement, do these things first:
Do not assume payment equals ownership.
List repositories, domains, cloud accounts, databases and third-party services.
Keep invoices, agreements, specifications and delivery records.
Find out who actually wrote the code.
Separate custom project work from third-party and pre-existing technology.
Your seven-day clean-up plan
- Obtain a complete repository backup.
- Move critical accounts into company-controlled ownership where appropriate.
- Compile a third-party/open-source component inventory.
- Identify every developer and subcontractor with material access.
- Review production-data access.
- Prepare a formal IP and technology agreement.
- Obtain legal review for the assignment/licence structure.
This is also a useful time to read Daily Reality NG's broader resources on Business Templates & Checklists Nigeria and the site's Research & Data Sources.
Your 30-day IP-control plan
Over the next month, turn the one-off developer relationship into a repeatable company system.
- Create a technology asset register.
- Standardise contractor IP agreements.
- Standardise confidentiality documentation.
- Make company-controlled repositories the default.
- Create an open-source approval process.
- Create developer access rules.
- Create a production-data access policy.
- Document software architecture.
- Schedule repository backups.
- Review all historic developer relationships.
- Regularise missing IP assignments.
- Review important trademarks and brand assets.
- Prepare a due-diligence folder.
For related corporate compliance work, Daily Reality NG also maintains resources on CAC registration in Nigeria, CAC annual returns and corporate tax issues for Nigerian companies.
The mistakes that create avoidable software-IP disputes
- Paying first and discussing ownership later.
- Using “work-for-hire” as a substitute for Nigerian drafting.
- Writing “all IP” without defining project IP.
- Ignoring background IP.
- Ignoring open-source licences.
- Letting the developer own the only repository.
- Giving unrestricted production-data access.
- Allowing undisclosed subcontractors.
- Failing to define acceptance.
- Leaving ownership timing ambiguous.
- Ignoring maintenance and future updates.
- Writing a termination clause without a handover checklist.
- Assuming source-code possession equals copyright ownership.
- Assuming copyright ownership equals ownership of every third-party component.
- Waiting until an investor asks for IP documents.
Frequently Asked Questions
1. Who owns software created by a developer in Nigeria?
It depends on the legal relationship, applicable law and contractual arrangements. For an independent developer, do not assume that the client automatically receives complete ownership simply because the client commissioned or paid for the work. The agreement should expressly establish the intended ownership or licensing structure.
2. Does paying a Nigerian developer mean I own the source code?
No. Payment and IP ownership are separate questions. The contract should identify what is being delivered and how the relevant IP rights are transferred or licensed.
3. Is a software development agreement necessary for a small Nigerian startup?
The smaller the company, the more damaging a major IP dispute can be. A short project still deserves a written agreement covering scope, ownership, confidentiality, third-party software, payment and handover.
4. What should an IP ownership clause contain?
It should identify the relevant project-created IP, establish whether ownership is assigned or rights are licensed, address timing, distinguish background IP, and account for third-party components and necessary licences.
5. What is an IP assignment clause in Nigeria?
An IP assignment clause is contractual language intended to transfer specified intellectual-property rights from one party to another. Copyright assignments and exclusive licences are subject to the written-form requirement in section 30 of the Copyright Act 2022.
6. Should I use “work-for-hire” in my Nigerian developer contract?
You should not rely on that phrase as a substitute for a properly drafted Nigerian ownership or assignment provision. State the commercial result you want and use an appropriate legal mechanism.
7. What is background IP?
Background IP is pre-existing technology or intellectual property brought into the project rather than created specifically for the client engagement. It should be identified and the client should receive whatever licence is necessary to use the finished product.
8. Should a developer sign an NDA?
An NDA or strong confidentiality clause can be appropriate where the developer receives confidential business or technical information. It should not be treated as a substitute for IP ownership provisions.
9. Who should own the GitHub repository?
For a company-owned product, it is generally safer for the company or its controlled organisation to own the principal repository, while the developer receives appropriate access permissions.
10. What happens if my developer uses open-source code?
The developer should disclose relevant components and their licences. Open-source software is governed by licence terms, so “free to use” should never be treated as a complete legal analysis.
11. Can my developer use subcontractors?
The agreement can regulate subcontracting. Where subcontractors are permitted, the principal developer should generally be required to ensure that relevant IP, confidentiality, security and data-protection obligations flow down appropriately.
12. Does a developer agreement need data-protection clauses?
If the developer processes personal data, the relationship may require appropriate data-protection terms and documentation. The exact requirements depend on the processing arrangement and applicable Nigerian data-protection framework.
13. What should happen when I terminate a developer?
The contract should require a structured handover covering source code, documentation, accounts, credentials, deployment information, outstanding work, licences and other project materials, with appropriate security procedures.
14. Can I use a developer's existing framework in my software?
Yes, potentially, but the agreement should identify it as background IP and provide the client with a suitable licence if the finished product depends on it.
15. Should a Nigerian startup have a lawyer review its developer agreement?
Where the software is commercially important, contains valuable IP, handles personal data, involves substantial money, uses complex licensing or is intended for investment or acquisition, professional legal review is strongly advisable.
What Daily Reality NG would check first
If we were auditing a Nigerian startup's software development relationship, we would not begin by asking whether the contract contains the words “intellectual property.”
We would begin with the asset itself.
Who created it? What exactly was created? Where is it stored? Who controls it? What existed before the project? What came from third parties? Who can access it? What happens if the developer disappears? And can the company prove all of this?
That is the practical meaning of IP protection.
The strongest technology agreement is therefore not necessarily the longest agreement. It is the agreement that accurately connects the commercial deal to the technical reality.
A founder who wants ownership but allows the developer to retain exclusive control of the repository has solved only part of the problem. A founder who controls the repository but has no contractual rights to third-party components has also solved only part of the problem. A founder who owns the code but gives a contractor unrestricted access to customer data has created another category of risk.
The objective is a complete chain:
That is the standard Nigerian technology founders should aim for before treating a development project as legally and commercially secure.
About the Author
Samson Ese is the founder of Daily Reality NG. Daily Reality NG publishes practical Nigerian-focused guides, analysis, explainers and research-led resources designed to help readers make better everyday business, technology and financial decisions.
Editorial disclosure
This article is an educational resource. It is not a template that should be signed without reviewing the facts of the particular transaction. Nigerian law can change, and a technology transaction may involve additional laws, regulations, licences or sector-specific requirements.
Disclaimer
Daily Reality NG does not provide legal representation through this article. Readers should obtain independent professional advice before signing or relying on a software development agreement, IP assignment, licence, NDA, data-processing arrangement or other legally binding technology contract.
Sources for the legal and IP framework include the Nigerian Copyright Commission's Copyright Act 2022 materials, WIPO's technology-transfer and software-IP guidance, and Nigerian data-protection guidance. The article's frameworks, scenarios, diagnostic tests and practical interpretation are editorial analysis by Daily Reality NG.
© 2026 Daily Reality NG — Empowering Everyday Nigerians.
Comments
Post a Comment