What Should Be Included in a Software Development Contract?

Custom software contracts fail in a different way from website contracts. The website dispute is usually about whether something was delivered. The software dispute is usually about whether what was delivered works well enough to run a business on, and about what happens when you want to change vendors three years later with four years of live operational data inside the system.

That second point is why the exit clause in a software contract matters more than almost anything else. This guide sets out the clauses that belong in a custom software agreement, written from a commercial and project perspective. It is not legal advice; have a qualified Nigerian lawyer review the final document.

Why software contracts carry more risk, and the clauses at a glance

Three features of custom software raise the stakes relative to a website build.

Dependency. Once orders, stock, patient records or payroll run through the system, you cannot simply stop using it. That dependency shifts negotiating power to whoever controls the code and the data.

Longevity. Business systems live for five to ten years. The contract has to work for a relationship that outlasts the people who signed it.

Operational data. The database accumulates value. Extracting it in a usable form later is a contractual question, not a technical inevitability.

The specification annex and change control

The specification belongs in an annex referenced by the contract, not in the operative clauses, so it can be updated by agreement without re-signing the whole agreement.

The annex should contain:

• A module list with a description of each module's purpose.
• User roles and permissions, including approval rights.
• Functional requirements written as testable statements: "A branch manager can approve a stock transfer up to a configured value."
• Non-functional requirements: expected concurrent users, response times, retention of records, availability expectations, audit logging.
• Reports required, with their fields and frequency.
• Explicit exclusions and deferred items.

Change control then defines the mechanism: a written change request, a vendor response within a stated period giving cost and schedule impact, your written approval before work begins, and an updated annex. For larger programmes, name the two people (one per side) authorised to approve changes. Without that, changes get agreed in corridors and invoiced later.

How to Create a Software Requirements Documentt place.

Phases, milestones and payment

Structure payment so that your exposure at any moment is smaller than the value delivered.

Indicative structure; adjust to project size. Actual figures vary with scope and vendor.

A retention holdback of 5–10% released at the end of the warranty period is common in larger contracts and is worth negotiating for any system your operations depend on.

Acceptance criteria, UAT and parallel running

This is the clause that ends projects cleanly.

Define:

• Acceptance criteria per module, drawn from the specification annex, written so that a test either passes or fails.
• A UAT window, commonly 10 to 20 working days for a business system, during which your nominated testers raise defects in a single written register.
• Defect severity levels. Critical (business cannot operate), major (a core function fails with no workaround), minor (cosmetic or inconvenient), each with a resolution target.
• Deemed acceptance. If you do not raise defects within the window, the module is accepted. Vendors need this, and it is reasonable provided the window is realistic.
• The defect-versus-change boundary. A defect is a failure to meet the annex. A change is a new requirement. Define it, because this determines who pays.
• Parallel running. For payroll, inventory, billing or clinical systems, run the new system alongside the existing process for at least one full cycle and compare outputs before retiring the old one.

Data migration, integrations and dependencies

Migration. The contract should state the source systems, the records to be migrated, the cut-off point for historical data, who cleanses the data, who validates the result, and how discrepancies are resolved. Data quality is usually your responsibility and the effort is usually underestimated. Name a person on your side who owns sign-off.

Integrations. For each integration, record the system, the direction of data, the method, the frequency, who supplies credentials, and, critically, whether the third-party system's interface has been confirmed to exist. Many packages used by Nigerian businesses have no public API, and "integration" then means scheduled file exchange.

Third-party dependency clause. Where delivery depends on a third party (an accounting vendor, a bank, a gateway), the contract should say what happens if that third party does not cooperate or changes its interface: who bears the delay, and how the scope is re-estimated. Without this clause, both parties argue about a delay neither caused.

Intellectual property, source code, escrow and people

Assignment. The vendor assigns to you, on payment, the intellectual property in the bespoke code, database schema, designs and documentation created for the project. Say explicitly that your operational data is and remains yours at all times, regardless of payment status.

Pre-existing materials. Vendors reuse internal frameworks and open-source libraries, which is normal and desirable. The contract should list them and grant you a perpetual, irrevocable, transferable licence to use, modify and have modified those components as part of your system, at no further cost. Without transferability, you cannot hand the system to another firm.

Open-source warranty. The vendor warrants that open-source components are used in compliance with their licences, and that none imposes obligations that would require you to publish your own code.

Source code delivery. Require a repository hosted under your organisation's account from day one, with the vendor added as a collaborator and code pushed at least at every milestone. This is stronger protection than a promise of delivery at the end and costs nothing.

Escrow. Where the vendor insists on holding the code, a source code escrow agreement with a third party, releasing on defined trigger events (insolvency, sustained breach, failure to support), is the fallback. For most Nigerian SMEs, owning the repository directly is simpler and cheaper.

Key personnel and subcontracting. Name the lead architect or project manager, require notice and an approved replacement of equivalent seniority, and require your consent before material parts of the work are subcontracted. Add a reciprocal non-solicitation clause with a modest duration so neither side poaches the other's staff.

Who Owns Custom Software Code?.

Security, data protection and the processing agreement

If the system holds personal data about customers, patients, pupils or staff, the Nigeria Data Protection Act 2023 imposes obligations on your business as controller. The vendor will usually act as a processor.

The contract should include a data processing annex covering:

• The categories of personal data and the purposes of processing.
• An obligation to process only on your documented instructions.
• Technical and organisational security measures: encryption in transit, access control by role, password and session policies, audit logging, secure handling of production data in development environments.
• Restrictions on using live personal data for testing without anonymisation.
• Sub-processor approval, including any overseas cloud providers, and where data is stored.
• Breach notification to you within a short, stated period, with the information you need to meet your own obligations.
• Deletion or return of personal data at the end of the engagement, with confirmation.
• Cooperation with data subject requests and with any regulatory enquiry.

Also address security testing: whether a penetration test is included before go-live, who pays, and who fixes the findings. Verify your own obligations with the Nigeria Data Protection Commission or a qualified adviser; this article does not constitute legal advice.

Warranty, support SLA and the rate card

Warranty. A defect-correction period after go-live, commonly 60 to 180 days for business systems, at no additional cost, covering failures to meet the specification annex. Warranty is not maintenance.

Support service level. Specify:

Indicative targets; agree levels appropriate to your operations and the price you are paying.

Also cover hours of cover, channels, escalation contacts, and what happens if targets are repeatedly missed, for example service credits against the retainer.

Rate card. Fix the day rate or hourly rate for enhancement work for at least the first two years, with any annual adjustment tied to a stated mechanism rather than the vendor's discretion. Include the annual support fee, indicatively in the region of 15–25% of build cost per year for custom business software, and state what it includes.

Termination, transition assistance and exit

For a system your business depends on, this is the most valuable clause in the document.

• Termination for convenience on written notice, with payment for work completed.
• Termination for cause with defined breaches and a cure period.
• Transition assistance. On termination or expiry, for a defined period (commonly 30 to 90 days), the vendor will provide, at agreed rates: a full database export in a documented, usable format; the current source code; environment and deployment documentation; configuration details; a knowledge-transfer session with your team or an incoming vendor; and cooperation with migration.
• No hostage provisions. State that the vendor will not withhold your operational data, and that access to your production environment and accounts cannot be suspended over a commercial dispute, which should follow the dispute clause instead.
• Credentials and accounts. All cloud, domain, gateway and service accounts are in your name throughout; the vendor's access is removed on request.
• Liability cap, typically linked to fees paid over a stated period, with mutually acceptable carve-outs, plus indemnities for intellectual property infringement and, from your side, for content and data you supply.
• Dispute resolution. Escalation between senior representatives, then mediation or arbitration in a named Nigerian city, then court. Nigerian governing law.

What changes for Nigerian software contracts

• Currency exposure. Cloud infrastructure, licences and AI or API usage are usually USD-priced. State which charges are USD-linked, how they will be converted, and the review mechanism. Avoid a fixed multi-year naira figure for a dollar cost.
• Tax treatment. Service invoices raise VAT and withholding tax questions. Say who bears VAT, and that withholding tax deducted at source will be evidenced by a credit note. Confirm the current position with your accountant or the Federal Inland Revenue Service.
• Corporate verification. Contract with the CAC-registered entity, use the registered name, and pay into a corporate account. Retain the transfer evidence.
• Power and connectivity. If the vendor hosts on premises, the contract must address power, cooling and internet redundancy and who funds them. A force majeure clause may reference extended grid failure, but not as cover for routine delay.
• Practical enforcement. Litigation is slow. Your real protections are structural: milestone payments, code in your repository, data exportable at any time, accounts in your name.
• Regulated sectors. Fintech, health and education systems may attract sector requirements from bodies such as the Central Bank of Nigeria or relevant professional regulators. Identify them early and confirm them directly rather than relying on the vendor's summary.

Example (hypothetical): the exit clause a Lagos clinic group needed

This is a hypothetical illustration, not a Linestech client project.

A three-branch clinic group in Lagos commissions a patient management system for ₦9,000,000. The contract includes a transition assistance clause requiring, on termination, a documented database export, current source code, deployment documentation and two knowledge-transfer sessions, all within 45 days at an agreed daily rate.

Four years later the vendor has reduced its team and response times have slipped. The clinic group decides to move. Because the export format and the assistance obligation were defined in advance, the successor firm receives four years of patient and billing records in a usable structure and rebuilds the reporting layer rather than the whole system. The migration takes eleven weeks.

The counterfactual is the common one: an undefined export obligation, a vendor with no incentive to cooperate, and a clinic group choosing between staying with a service it has outgrown and re-entering four years of records by hand.

Contract review checklist

• The vendor's CAC-registered name and number are correct
• A specification annex is attached and referenced
• Change control names approvers and a pricing method
• Payments are tied to inspectable phase deliverables
• A retention holdback is held until warranty expiry
• Acceptance criteria exist per module, with a UAT window
• Defect severity levels and the defect-versus-change boundary are defined
• Parallel running is provided for where operations depend on the system
• Data migration scope, validation and sign-off are assigned
• Each integration is named, with feasibility confirmed
• IP is assigned and pre-existing components licensed transferably
• The code repository is in your organisation's account
• Escrow is in place if the vendor holds the code
• Key personnel and subcontracting are addressed
• A data processing annex reflects NDPA 2023 duties
• Security measures and breach notification are specified
• Warranty is separate from maintenance and has a defined period
• An SLA with severity levels and remedies is included
• A rate card fixes future work pricing
• Transition assistance on exit is defined, with formats and timescales
• Your operational data cannot be withheld in a dispute
• Liability, indemnity, governing law and dispute steps are covered

Conclusion

A custom software contract is a long-term operating agreement wearing the clothes of a build contract. Write it for the five-year relationship, not the six-month project: specification annex, acceptance criteria you can test, migration and integration responsibilities assigned, code in your own repository, a data processing annex, an SLA with real remedies, a fixed rate card, and transition assistance that lets you leave.

Keep the payment structure conservative, keep your data exportable at all times, and make sure that nothing your business depends on sits in an account bearing someone else's name.

If you are commissioning a custom system and want the scope, acceptance criteria and handover terms defined before drafting begins, Linestech can work through your requirements and set out what should be documented.

Frequently asked questions

Is source code escrow worth the cost for a Nigerian SME?

Usually not, if you can instead own the repository from day one with code pushed at every milestone. Escrow adds a third party, an annual fee and a release process that must be triggered. Escrow is more relevant where the vendor licenses a product it also sells to others and genuinely cannot hand over its codebase.

What should the contract say about the database?

That the operational data is your property at all times, that you may export it at any time in a documented format, and that a full export is provided on request and on exit. Data ownership should not be conditional on payment status, even where code ownership is.

How long should the warranty period be?

Sixty to one hundred and eighty days after go-live is common for business systems, and longer periods are reasonable for systems with seasonal cycles such as payroll or school administration, where some functions are only exercised once a term or once a year. Match the period to when each function will first be used in anger.

Should I agree to deemed acceptance?

Yes, provided the window is realistic and the criteria are objective. Vendors cannot leave projects open indefinitely. Negotiate the length of the window and make sure your testers are actually available during it, because a deemed acceptance clause you cannot meet is a clause that works against you.

Can I include penalties for late delivery?

Liquidated damages linked to milestone dates are possible but must be a genuine pre-estimate of loss rather than a punishment, and they invite the vendor to pad the schedule. A more practical alternative is a retention holdback plus the right to terminate for sustained delay. Take legal advice on drafting.

Who owns the specification produced during a paid discovery phase?

You should, if you paid for it. Say so explicitly, and state that you may share it with other vendors for quotation. This is the clause that keeps a discovery phase from becoming a commitment to the firm that ran it.

What if the vendor is an individual rather than a company?

The contract can still work, but the risks concentrate: no team continuity, limited recourse, and dependency on one person's availability. Strengthen the repository, documentation and transition clauses, keep milestones small, and consider whether the system's importance justifies a firm with more depth.

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)
• Central Bank of Nigeria (CBN)
• PostgreSQL documentation
• GitHub documentation
• OWASP Top 10