Custom development work is one of the most common ways early startups earn revenue. A bank or a large company pays the startup to build something on top of its platform, and the customer usually assumes it will own whatever it has paid for, while the startup needs to keep its platform and reuse what it learns on the next project. Both positions are reasonable, and the contract has to reconcile them.
That means the contract should describe exactly what is being built and who owns each part, together with the licences each side needs once the project ends. In my experience it is far easier to agree these points alongside the scope and payment terms than to argue about them after delivery.
Describe the work and how it is accepted
The contract should include a statement of work listing the deliverables and the timetable, and setting out what the customer must provide. It should also say what happens when the customer is late in providing data or access, because that is one of the most common reasons projects slip. Any extra work should go through a change process that agrees the price and timing before the engineers begin.
The acceptance period and acceptance criteria should be ones both sides can actually test. The contract should explain how defects are reported and fixed, and whether silence or going live counts as acceptance, and it should link payment and any transfer of ownership to that process, including what happens while a milestone is in dispute.
The statement of work and the master agreement should describe the same project, and the contract should say which document applies if they conflict. I explain how the delivery team can keep changes and acceptance records in order in keeping track of contracts as the business grows.
Draw the ownership line around the actual materials
The starting point is to identify the startup's background technology, meaning the platform and code it owned or licensed before the project began. That background technology should be separated from the deliverables the customer is paying for, and the contract should say who owns general improvements made during the project that could be used for other customers. If the customer wants exclusivity, its scope and length should be agreed, and the price should reflect the business the startup is giving up.
If deliverables are to be assigned to the customer, the startup must own them first, which means it needs assignments from its own developers and contractors. The transfer to the customer should be in writing and signed, as the Copyright Act 2022 requires, and the contract should make clear that open‑source and other third‑party components remain subject to their own licences.
Where ownership passes only on payment, the customer will need a licence to test and use the work before then, and the contract should say what happens to that licence if payment is late or disputed. The payment records should be kept with the transfer documents, so that both sides can show when ownership passed.
Give each side a licence it can use
If the deliverable depends on the startup's platform, the customer needs a licence to use the platform for as long as it uses the deliverable. The licence should say who may use it, including affiliates and service providers, and whether it continues after support ends.
The startup, for its part, needs permission to use the customer's data and materials during the project and for any agreed purpose afterwards, such as support. That permission should be set out next to the clause confirming the customer's ownership of its own materials.
The assignment and change‑of‑control clauses also need attention. If the startup is sold, or moves the contract into a new group company, it may need the customer's consent, so it is sensible to agree any permitted transfers at the outset.
Third‑party claims and remedies
An IP warranty should cover the deliverable while excluding anything the startup disclosed in advance and anything the customer supplied. An IP indemnity should define the claims it covers and the notice required, and say who controls the defence, including what happens if a settlement would restrict the customer's use of the product.
The usual remedies are obtaining a licence for the customer or changing the work so that it no longer infringes, with replacement as the other option. If none of those is possible, the last resort is often a refund, and the contract should then deal with help for the customer in moving to another solution.
The contract should also make clear whether IP claims fall under the general liability cap or a separate, higher cap. Many large customers insist on a separate cap, so the startup should read the exclusions and understand its real exposure before signing.
Personal data is a separate subject
If the project involves personal data, the roles of each party have to be clear under the Nigeria Data Protection Act. Usually the customer is the controller and the startup is the processor acting on the customer's instructions, so a data processing agreement should be put in place covering security and any subcontractors or access from outside Nigeria.
If the startup wants to use project data for analytics or to improve its product, that should be dealt with openly in the contract. Data remains personal data if someone can be identified from it, whatever label it is given, and any product‑improvement use has to be consistent with the processing agreement.
Plan for the end of the relationship
Support and maintenance should have their own term and service levels, and the contract should say who fixes defects after the system goes live and on what charges. If the customer asks for source code escrow, the startup should check that the release events and the licence would actually allow the customer to maintain the system, and that the deposit includes build instructions as well as the code itself.
Transition help and documentation at the end of the contract should be agreed, including their cost and duration. The licences that survive termination decide what the customer can continue to use and what the startup can reuse, so the signed assignments and licences should be stored together, since the people who negotiated them will often have moved on by the time anyone needs them.
This article is general information and not legal advice. For guidance on your specific circumstances, speak with us directly.