1. Home
  2. Blog
  3. Mobile App Development
  4. What Should Be Included in an App Development Contract?

What Should Be Included in an App Development Contract?

Business colleagues in a meeting with a tablet in an office — an article about app development contract

Most disputes between Nigerian businesses and app developers are not about bad faith. They are about two parties who remembered a WhatsApp conversation differently. The contract exists to make the conversation unnecessary: what is being built, by when, for how much, who owns it, and what happens when something changes or goes wrong.

This guide walks through the clauses an app development contract should contain, explains why each matters in practice, and flags the points where Nigerian businesses are most often exposed. It applies whether you are hiring an agency or an individual developer, and whether the app is a small MVP or a large system. It is written from a project-management and commercial perspective rather than a legal one; have a qualified lawyer review your contract before signing.

Why a proper contract matters more than the price

A contract does three jobs. It records what both sides agreed so that memory is not the referee. It allocates risk so that each side knows what it is responsible for. And it defines the exits so that if the relationship fails, the business still ends up with its code, accounts and data.

For a Nigerian business, the third job is the one most often neglected. Litigation is slow and expensive, so a contract's practical value lies in structuring the deal so that you never need to sue: milestone payments, weekly code delivery, accounts in your name, and a handover clause.

The clauses at a glance

ClauseWhat it fixesRisk if missing
Parties and definitionsWho is contracting with whomContracting with an individual when you thought it was a company, or vice versa
Scope of workExactly what will be builtEndless "that was not included" disputes
Deliverables and milestonesWhat you receive and whenPaying for time with nothing to show
Payment scheduleHow much, when, tied to whatLarge upfront payments with no recourse
Timeline and client obligationsDates and what you must provideDelays blamed on each other
Change requestsHow additions are priced and approvedScope creep, cost overruns
Intellectual propertyWho owns code, designs, contentDeveloper retains your product
Accounts and credentialsWhose name is on hosting, stores, gatewayLocked out of your own app
Acceptance testingHow "done" is decidedEndless arguments about completeness
WarrantyBug fixing after delivery, for how longPaying to fix defects in new work
ConfidentialityProtection of your business informationIdeas and data shared elsewhere
Data protectionObligations under the NDPA 2023Regulatory exposure for you
Maintenance and supportPost-launch terms and ratesHostage pricing after launch
Termination and handoverHow either side exits and what is handed overLosing everything if the relationship ends
Liability and indemnityLimits and protections on both sidesUncapped exposure or no recourse
Governing law and disputesWhich law, and how disputes are resolvedUncertainty and delay

Scope of work and deliverables

The scope of work is the heart of the contract. It should describe the app in enough detail that a third party could judge whether it was delivered.

Include, usually as an attached schedule:

  • The feature list for this version (the Must list from your brief), each feature described in a sentence or two.
  • The platforms (Android, iOS, web) and minimum supported versions.
  • Integrations by name: payment gateway, SMS or WhatsApp provider, maps, email.
  • The admin functions you will have.
  • Non-functional requirements: performance on low-end devices, behaviour on poor connections, security basics, data export.
  • Design deliverables: number of screens, design files.
  • Documentation and training to be delivered.
  • What is explicitly excluded (content, marketing, store listing assets, legal documents, if that is the case).

If the scope is a single sentence, the contract cannot protect you. If it is a fifty-page specification, it will not be read. Aim for two to six pages of clear, structured description, referencing your sketches.

Timeline, milestones and payment

Milestones convert the scope into checkpoints. Each milestone should name a deliverable you can inspect, a date, and the payment released on acceptance.

A typical structure for a three-month MVP (indicative; adapt to the project):

MilestoneDeliverableIndicative payment share
1. Kick-offSigned contract, project plan, access set up25–30%
2. Design approvedClickable design of all screens, approved in writing15–25%
3. Core loop workingWorking build on a real device completing the main journey with a real test payment25–30%
4. Test-ready buildAll scope complete, tested on agreed devices, ready for acceptance10–20%
5. Launch and handoverStore submission or web deployment, code, documentation, credentials10–15%

The contract should also state your obligations: providing content, test users, decisions and approvals within defined periods (for example, feedback within five working days). Delays caused by your side should extend the timeline, not create a dispute.

Avoid paying more than about a third upfront, and avoid schedules where the developer has no incentive to finish because most of the money has been paid.

Change requests

Changes will happen. The contract should say how:

  • Any addition or change to the scope is requested in writing.
  • The developer responds with an estimate of cost and schedule impact within a defined period.
  • Nothing is built until you approve the estimate in writing.
  • Approved changes are appended to the scope schedule.

Some contracts include a small allowance for minor changes (for example, up to a set number of hours) to avoid paperwork for trivial tweaks. State the hourly or daily rate for changes so that it is not negotiated under pressure later.

Intellectual property and code ownership

For most businesses, this is the most important clause after scope. The contract should state that, upon final payment, you own the intellectual property in the source code, designs, documentation and any content created specifically for the project, and that the developer assigns those rights to you.

Points to address:

  • Assignment on payment. Ownership transfers as milestones are paid, or in full on final payment; make sure the trigger is clear.
  • Pre-existing and third-party components. Developers reuse libraries and their own tools. The contract should list any such components, confirm that they are licensed to you for use in the app without further payment, and confirm that no component prevents you from modifying or transferring the app.
  • Open-source licences. The developer should warrant that open-source components are used in line with their licences and that none require you to publish your own code.
  • Moral rights and portfolio use. Agree whether the developer may show the project in their portfolio, and on what terms.
  • Source code delivery. Ownership on paper is worthless without the code. Require delivery to a repository you control, with commits throughout the project, not only at the end.

A related article covers who owns code after app development in more depth, including what happens when the clause is missing.

Accounts, credentials and third-party services

The contract should require that all accounts used by the app are created in the name of your business and that the developer works with delegated access:

  • Domain registration
  • Hosting and cloud services
  • Google Play and Apple developer accounts
  • Payment gateway merchant account
  • SMS, email, WhatsApp Business Platform and any other service
  • Code repository
  • Analytics and monitoring

Include a clause requiring the developer to hand over all credentials on request and at handover, and to remove their own access when instructed. Practical experience across many projects is that account ownership, not code ownership, is where businesses most often lose control of their app.

Acceptance testing and warranty

Acceptance defines "done". The contract should specify:

  • The test devices and conditions (for example, at least two named low-end Android devices and one iPhone, on a mobile data connection).
  • The test scenarios: the core journeys, payment success and failure paths, no-network behaviour.
  • The acceptance period (for example, ten working days for you to test each milestone) and the process for reporting defects.
  • What counts as a defect (something in scope that does not work as described) versus a change (something new).
  • Deemed acceptance if you do not respond within the period, which is fair to the developer.

The warranty then covers defects discovered after acceptance for a stated period, commonly four to twelve weeks, at no extra cost. It should exclude problems caused by your changes or by third-party services, and it should define response times for critical issues such as payments failing.

Confidentiality and data protection

Confidentiality should cover your business information, your customer data, and the details of the app itself, for the project period and a reasonable time afterwards. A separate non-disclosure agreement is often signed before the contract; the contract can incorporate it.

Data protection is a distinct obligation. Under the Nigeria Data Protection Act 2023, your business is responsible for personal data your app collects, and the developer will handle that data while building and possibly maintaining the app. The contract should require the developer to:

  • Process personal data only on your instructions and for the project.
  • Apply reasonable security measures, and not copy production data to insecure places.
  • Notify you promptly of any breach.
  • Delete or return data at the end of the engagement.
  • Assist you with reasonable requests related to compliance.

Check current NDPC guidance on the exact obligations and whether your business needs to register or appoint a data protection officer at your scale; verify with the Commission or a professional.

Maintenance, support and post-launch rates

The period after launch is where pricing surprises happen, because the business has no leverage once the app is live. Fix the terms before the build starts:

  • Whether maintenance is included, for how long, and what it covers (bug fixes, OS updates, security patches, monitoring, small changes).
  • The monthly or yearly maintenance fee, with an indicative reference of 15–25% of build cost per year being common.
  • Response and resolution times for critical, major and minor issues.
  • The hourly or daily rate for work outside maintenance.
  • How long the developer will keep supporting the current version if you stop paying for maintenance.

Even if you plan to handle maintenance in-house or with another provider, having the option priced in the contract is valuable.

Termination, handover and dispute resolution

The exit clauses protect you when the relationship ends, whether amicably or not:

  • Termination for convenience: either party may end the contract with notice (for example, 30 days); you pay for work completed and accepted up to that point.
  • Termination for breach: either party may end it if the other fails to fix a serious breach within a cure period.
  • Handover on termination: regardless of the reason, the developer delivers all code, designs, documentation and credentials for the work paid for, and removes their access.
  • Survival: confidentiality, IP assignment and data protection survive termination.
  • Governing law: usually the laws of the Federal Republic of Nigeria for a Nigerian project.
  • Dispute resolution: a staged process is practical: negotiation between senior people, then mediation, then arbitration or the courts. Arbitration under Nigerian arbitration rules can be faster than litigation; a lawyer can advise which suits your situation.
  • Liability: a cap on each side's liability (often the contract value) with carve-outs for confidentiality breaches, IP infringement and wilful misconduct.

What changes for contracts in Nigeria

  • Enforcement is slow, so structure beats litigation. Milestones, weekly code delivery and accounts in your name protect you in practice; the legal remedies are a backstop.
  • Contract with a registered entity where possible. Check the counterparty's CAC registration and put the registered name and RC or BN number in the contract. If contracting with an individual, use their full legal name and address.
  • Currency and exchange rates. State the currency of the contract. If any element is priced in US dollars (some developers and most hosting), state how conversion is handled and when. Fixing naira amounts protects your budget; fixing dollar amounts protects the developer; agree which and why.
  • Taxes. Clarify whether the price includes VAT and how withholding tax, where applicable, is handled. Verify the current position with FIRS or an accountant; the contract should not leave it to assumption.
  • Payment method and timing. Bank transfer with invoices is standard; state the days allowed for payment after milestone acceptance.
  • Data protection is law, not preference. The NDPA 2023 applies; the clause is not optional.
  • Regulated sectors. If the app is subject to CBN, NHIA or other regulatory requirements, the contract should say who is responsible for meeting them and for obtaining any approvals; usually this is you, with the developer building to specified requirements.
  • Stamping and execution. Some contracts benefit from stamping under Nigerian stamp duties law to be admissible in court; ask your lawyer whether it applies to your agreement.

Example (hypothetical): how a contract clause saved a project in Ibadan

This example is hypothetical and is included to illustrate the clauses in action; it does not describe a real business or a Linestech client.

A private hospital group in Ibadan contracts a small agency to build a patient appointment and results app, with a fixed price of ₦7,500,000 (indicative) over four months and five milestones.

At milestone three, the agency's lead developer leaves. The agency asks for a two-month extension and an additional ₦1,200,000 to onboard a replacement. The hospital's contract contains three relevant clauses: milestone payments tied to accepted deliverables (only 55% had been paid), a requirement that code be committed weekly to the hospital's repository (it had been), and a termination-for-convenience clause with handover.

The hospital has options it would not otherwise have. It can accept a shorter extension at no extra cost, which the agency agrees to because it wants the remaining 45%; or it can terminate, take the code it has paid for, and hire another developer to finish. It chooses the first, with a revised milestone schedule appended as a written change. Without the clauses, the hospital would have faced a choice between paying more and starting again.

Contract review checklist

Before signing, confirm each item:

  • Both parties are correctly identified, including CAC registration where applicable
  • Scope schedule describes every feature, platform, integration and exclusion
  • Milestones name inspectable deliverables with dates
  • Payment is tied to milestone acceptance; upfront share is reasonable
  • Your obligations and response times are stated, and delays on your side extend the timeline
  • Change requests require written estimate and approval; rates are stated
  • IP in code, designs and documentation is assigned to you on payment
  • Third-party and pre-existing components are listed and licensed to you
  • All accounts are in your business's name; credentials handed over on request
  • Code is delivered to your repository throughout the project
  • Acceptance devices, scenarios and periods are defined
  • Warranty period, coverage and response times are stated
  • Confidentiality and NDPA 2023 data protection obligations are included
  • Maintenance scope, fee and post-launch rates are stated
  • Termination, handover and survival clauses are present
  • Currency, VAT and tax treatment are clear
  • Governing law is Nigerian and dispute resolution is staged
  • Liability is capped with sensible carve-outs
  • A Nigerian lawyer has reviewed the document

Mistakes that leave businesses exposed

  • Using the developer's contract without reading it. Developer-drafted contracts often keep IP with the developer and limit warranty. Read every clause or have a lawyer do so.
  • A one-line scope. "Develop a mobile app for the client" protects no one.
  • Paying half or more upfront. It removes your leverage and the developer's urgency.
  • No repository or account clauses. Ownership on paper without possession in practice.
  • Ignoring the post-launch rates. Maintenance pricing negotiated after launch is negotiated from weakness.
  • No acceptance criteria. "Done" becomes an argument.
  • Assuming a contract replaces management. The contract sets the rules; weekly demos and prompt decisions keep the project healthy.

Conclusion

An app development contract should describe precisely what is being built, tie payment to inspectable milestones, assign code and designs to you, put every account in your name, define how changes and acceptance work, cover confidentiality and NDPA 2023 data protection, fix post-launch rates, and set out how either side can exit with a proper handover. Those clauses do more than give you recourse; they shape the project so that recourse is rarely needed. Use the checklist, insist on the ownership and accounts clauses without exception, and have a Nigerian lawyer review the final document.

Linestech's standard agreement for app development covers these clauses, including full IP assignment, accounts in the client's name and a defined handover. If you would like to see how we structure scope and milestones for a project like yours, we can walk you through it before you commit to anything.

Frequently asked questions

Do I need a lawyer for an app development contract in Nigeria?

For anything beyond a very small project, yes, at least for a review. A lawyer familiar with technology contracts can check the IP, liability, tax and dispute clauses and adapt the template to your situation. The cost of a review is small relative to a typical app budget and to the cost of a dispute.

What if the developer says their standard contract cannot be changed?

Reputable developers and agencies expect negotiation on scope, milestones, IP and warranty. A refusal to discuss any changes, especially on ownership or accounts, is a reason to choose another vendor. Small changes to liability or portfolio-use clauses are normal give-and-take.

Should the contract be in naira or dollars?

For a Nigerian client and vendor, naira is usually simplest and protects your budget. If the vendor insists on dollar pricing, agree the conversion mechanism and timing in the contract. Third-party services that are inherently dollar-priced (hosting, some tools) should be identified as pass-through costs with an estimate.

What happens if the app is delivered late?

The contract should say. Common approaches are an agreed extension where the delay is caused by your side, and remedies such as a reduction in the final payment or a right to terminate and take the code where the delay is caused by the developer beyond a grace period. Punitive penalties are rarely productive; clear remedies and milestones are.

Is an NDA the same as the development contract?

No. A non-disclosure agreement protects your information during early discussions before any contract is signed. The development contract governs the actual work and usually includes its own confidentiality clause. Sign an NDA before sharing a detailed brief, then sign the development contract before work begins.

Who is responsible for compliance with regulators such as the CBN or NDPC?

Usually the business, because it is the entity operating the app and holding the data; the developer's responsibility is to build to the requirements you specify and to handle data properly during the project. The contract should state this clearly, and you should verify the applicable requirements with the relevant regulator and a qualified professional before defining the scope.

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.