Outsourcing App Development in Nigeria: What to Control

Apps carry one obligation that websites do not: they live inside other companies' distribution systems. Apple and Google decide whether your app is published, under what account, and whether it continues to comply with their policies. An outsourcing arrangement that ignores this hands a supplier control over your presence on your customers' phones.
This guide follows the outsourced app project from first conversation to year-two maintenance, with the accounts, artefacts and acceptance criteria you should insist on at each stage. If you are still deciding whether to use a freelancer or an agency, read Freelancer vs Agency for App Development.
What outsourcing app development involves
An outsourced app engagement usually covers more than writing mobile code. A complete scope includes product definition, UI/UX design, the mobile application itself, a backend with an API and database, an admin dashboard your staff will use daily, integrations such as payments and notifications, testing across devices, store submission, and post-launch support.
Vendors differ enormously in how much of that they include by default. The commonest source of disappointment in Nigerian app projects is a quote that covered the phone screens and quietly excluded the backend, the admin dashboard and the store submission — the three items that turn an app into a working business system.
So the first job when outsourcing is not choosing a vendor. It is writing down all nine components above and asking each vendor which they are quoting for.
The six stages of an outsourced app project
| Stage | What happens | What you should receive | Typical duration |
|---|---|---|---|
| 1. Discovery | Requirements, user roles, flows, scope decisions | Requirements document, screen list, phased plan | 1–3 weeks |
| 2. Design | UI screens, states, navigation, design system | Clickable prototype and final designs | 2–4 weeks |
| 3. Build | Mobile app, backend, admin dashboard, integrations | Weekly demos and an installable test build | 6–20 weeks |
| 4. Testing | Device testing, integration testing, user acceptance | Test report, bug list, fixed build | 2–4 weeks |
| 5. Release | Store listings, submission, review responses | Live apps under your accounts, listing assets | 1–4 weeks |
| 6. Handover and support | Code, credentials, documentation, training | Handover pack, training session, support agreement | 1–2 weeks, then ongoing |
Two stages get compressed when budgets are tight, and both cost more later. Discovery is where scope disputes are prevented. Testing is where your users' experience is decided — an app that works on the developer's phone and fails on a four-year-old Android device will be uninstalled within a day.
Insist that both stages appear as named, priced line items in the proposal. If a vendor has folded them invisibly into "development", ask how many days each will take.
What you must own before development starts
Set these up in your own business's name before the project begins, then add the vendor as a user. Retrofitting them afterwards is difficult and sometimes impossible.
- [Apple Developer Program](https://developer.apple.com/programs/) account in your company's name. The Apple Developer Program carries a yearly fee (historically US$99 per year — verify the current fee with Apple). An organisation account requires company verification, so start early.
- [Google Play Console](https://play.google.com/console/about/) account in your company's name. Google Play developer registration is a one-time fee (historically US$25 — verify the current fee with Google).
- Signing credentials under your control. For iOS, the certificates and provisioning profiles sit within your Apple account. For Android, releases are signed; where Play App Signing is used, Google manages the app signing key while you retain the upload key. Either way, make sure the Play Console account and the upload key are held by your business and backed up, and confirm in writing what the vendor holds.
- Source code repository created under your organisation's account, with the vendor invited as a collaborator.
- Cloud and backend accounts — hosting, database, storage — registered to your business, with billing on your card or account.
- Third-party service accounts — payment gateway, SMS or OTP provider, push notification service, analytics, error reporting, maps.
- Domain and email used for the app's API, support address and privacy policy page.
If a vendor resists any of these, ask why. There are legitimate operational reasons for shared access during development; there is no good reason for permanent exclusive control.
Indicative costs and what drives them
Indicative 2026 naira ranges. Actual quotes vary with scope, vendor and exchange rate, since cloud services, store fees and tooling are USD-priced.
| App type | Indicative one-off cost | What it typically includes |
|---|---|---|
| Simple MVP | ₦1,500,000–₦5,000,000 | One or two user flows, basic backend, one or both platforms |
| Medium business app | ₦5,000,000–₦15,000,000 | Accounts, payments, notifications, admin dashboard, integrations |
| Complex platform | ₦15,000,000–₦50,000,000+ | Marketplace or fintech features, multiple roles, real-time behaviour |
| Annual maintenance | 15–25% of build cost per year | OS updates, library upgrades, bug fixes, small improvements |
The cost drivers, in order of impact: the number of distinct user roles (each is effectively another app), whether money moves through the app, how many external systems it integrates with, whether you need both platforms at launch, real-time features such as live tracking or chat, and the level of design polish.
Recurring costs beyond maintenance include cloud hosting from roughly ₦150,000 per year upward, SMS or OTP charges per message, push notification services, payment gateway transaction fees and store fees. Ask for these as a separate written list with the currency stated. How to Budget for App Development in Nigeria.
Milestones and acceptance criteria that protect you
Vague milestones are why outsourced app projects end in argument. Replace percentage-complete reporting with things you can install and use.
A workable structure for a Nigerian app project:
- Discovery accepted (10–15%) — requirements document and screen list signed off by you.
- Designs approved (15–20%) — clickable prototype covering every screen and empty, loading and error states.
- First installable build (20%) — a test build on your own phone with core navigation and one complete user journey working.
- Feature complete (20%) — all agreed features present in a test build, backend and admin dashboard operational.
- User acceptance passed (15–20%) — your own staff or test users complete the agreed scenarios on real devices.
- Live and handed over (10–15%) — apps published under your accounts, handover pack delivered, training completed.
Write acceptance criteria in business language, not technical language. "A customer can register with a phone number, receive an OTP, add a delivery address, pay with card or bank transfer, and receive a confirmation" is testable. "Payment module complete" is not.
Add a warranty clause: defects reported within 30–90 days of launch are fixed at no charge. What Should Be Included in an App Development Contract?.
Beta testing and store release
This is the stage most Nigerian buyers underestimate, and it is entirely predictable.
Beta testing. Before public release, distribute a build to 10–30 real users through TestFlight on iOS and internal or closed testing tracks on Google Play. Test on a genuine spread of devices — at least one older mid-range Android phone, not only recent models — and on mobile data rather than office Wi-Fi. Require the vendor to fix what beta testing finds before release, and budget time for it.
Store listing assets. Someone must produce the app name, short and full descriptions, screenshots at the required sizes, an icon, a feature graphic for Google Play, a support URL, a privacy policy URL and content ratings. Agree in the contract who writes these; vendors often assume you will, and you often assume they will.
Review and rejection. Both stores review submissions and rejections are routine, not a sign of failure. Common causes include missing or inadequate privacy declarations, no in-app account deletion route where required, permissions requested without justification, incomplete test credentials for the reviewer, and thin apps that are little more than a wrapped website. Build two to four weeks into the schedule for submission and possible resubmission, and make it explicit that the vendor handles rejection responses within the contract price.
Policy changes continue after launch. Store requirements evolve, and an app that complied last year may need changes this year. That is a maintenance obligation, not a one-off task.
Maintenance: the part that is not optional
An unmaintained app degrades faster than any other software asset a Nigerian business owns. Over two years it will typically need compatibility work for new Android and iOS versions, library and SDK upgrades, changes when a payment provider updates its integration, responses to store policy changes, and fixes for issues that only appear at scale.
Agree the support arrangement before launch, while you still have commercial leverage. Specify:
- What is covered — bug fixes, OS compatibility, store compliance, minor changes — and what is charged separately.
- Response times by severity. For example: app cannot start or payments fail, response within 4 working hours; significant feature broken, within 1 working day; minor issue, within 5 working days.
- Monthly or annual price, typically 15–25% of build cost per year.
- Included hours for small improvements, and the rate beyond them.
- Who holds the release keys and who publishes updates.
- Notice period and exit, including a final handover if you change vendor.
What Happens After Your App Is Launched?.
What changes for Nigerian businesses
Device range is wide and skews mid-range Android. Test on phones your customers actually use, including devices with limited storage and older Android versions. App size and cold-start time matter: users delete large, slow apps to free space.
Networks are inconsistent. Specify offline and poor-connection behaviour in the requirements — queued actions, clear retry prompts, small payloads, no infinite loading screens. If this is not written down, it will not be built.
Payments need live testing. Card, bank transfer, USSD and wallet journeys through Paystack, Flutterwave, Interswitch or Moniepoint behave differently in an app than on the web. Require testing in sandbox and with small live transactions, including failed and pending states, before acceptance.
Data protection obligations sit with you. Under the Nigeria Data Protection Act 2023, your business is responsible for personal data the app collects, even though the vendor built it. Include data-processing terms in the contract and publish an accurate privacy policy. Verify current requirements with the Nigeria Data Protection Commission (https://ndpc.gov.ng/); this is not legal advice.
Organisation account verification takes time. Setting up developer accounts in a company's name requires documentation and verification steps. Start this in week one, not the week before launch.
Foreign-currency running costs. Store fees, cloud hosting, notification and analytics services are USD-priced, so your monthly cost moves with the exchange rate. Budget in naira with headroom.
Vendor verification. Confirm the CAC-registered name matches the account you pay, and check the vendor's published apps on the stores yourself. How to Avoid App Development Scams in Nigeria.
Example (hypothetical): a retailer outsources a loyalty app
The following is a hypothetical illustration, not a Linestech client result.
A supermarket chain with six branches in Lagos and Ibadan wants a loyalty app: customers scan at the till, earn points, receive offers and see a digital card.
Before contracting, it opens its own Apple and Google accounts, creates a repository under the company organisation, and sets up its own cloud account. This takes three weeks, running in parallel with vendor selection.
Scope agreed: customer app for Android and iOS, a till-side scanning flow, a points engine, an offers module, an admin dashboard for the marketing team, and integration with the existing point-of-sale system. Indicative price ₦7,800,000 over four months.
Milestones: designs approved; first installable build with sign-up and card display; feature complete including till integration; user acceptance across three branches; live in both stores with handover.
What testing catches: in branch acceptance testing, the scan flow fails when the network drops at the till — a common occurrence at the Ibadan branch. The fix is an offline queue that syncs when the connection returns. Because this is found before release rather than after, it is handled inside the build.
After launch: a ₦1,600,000 annual support agreement covering OS updates, store compliance, bug fixes and eight hours a month of small changes, with a four-hour response commitment for anything that stops customers earning points.
The pattern worth copying is that the retailer controlled the accounts, tested in the real environment, and priced support before signing.
How to verify an app outsourcing partner
- Install their apps. Ask for store links, not screenshots. Use two of them on your own phone and judge speed, stability and polish.
- Confirm credit. Ask what specifically they built on each app and who else was involved.
- Ask which devices they test on. A serious answer names physical phones and Android versions.
- Ask how they handle store rejections. Experience shows in the specifics they mention.
- Check company substance. CAC registration, verifiable address, company bank account, named team members.
- Speak to a past client, ideally one whose app is a year or more old, and ask about support responsiveness.
- Ask what the handover pack contains. A prepared answer is a strong signal.
How to Choose an App Development Company in Nigeria.
Implementation checklist
- Write the requirements document with screens, roles and acceptance criteria.
- Open Apple and Google developer accounts in your business name.
- Create the code repository and cloud accounts under your organisation.
- Shortlist three vendors and send the identical brief.
- Require itemised quotes covering design, mobile, backend, admin dashboard, testing, store submission and support.
- Agree milestones tied to installable builds, with staged payments.
- Appoint one internal owner with decision authority.
- Run weekly demos with written notes and a dated change log.
- Conduct beta testing on real devices over mobile data.
- Agree who produces store listing assets.
- Confirm the privacy policy is published and accurate before submission.
- Complete user acceptance testing with your own staff or customers.
- Receive the handover pack: code, credentials, documentation, training.
- Start the support agreement on the day of launch, not later.
Mistakes to avoid
- Letting the vendor open the store accounts. Moving a published listing later is difficult and you may lose ratings and reviews.
- Paying against progress reports rather than installable builds. Insist on something you can put on your phone.
- Skipping the admin dashboard. Without it, your staff run the app through the vendor, permanently.
- Testing only on new phones. Your customers are not all on recent flagships.
- Treating store submission as the vendor's private problem. Agree in the contract that they handle rejections within the price.
- Leaving maintenance to be negotiated after launch. Leverage disappears the moment the final payment clears.
- Ignoring the privacy policy and data declarations. They cause rejections and carry obligations under the NDPA.
- Accepting a zip file of code instead of repository access. You want the history, not a snapshot.
- Forgetting recurring costs. SMS, notifications, hosting and store fees continue whether or not anyone uses the app.
Conclusion
Outsourcing an app is less risky than it is often made to sound, provided you keep control of three things: the developer accounts and release credentials, the code repository, and the payment schedule. Everything else — scope disputes, rejections, bugs, delays — is manageable when those three sit with you.
Write acceptance criteria you can test on your own phone, put discovery and testing in the plan as named stages, and agree maintenance before launch rather than after. An app is a multi-year commitment from the day it goes live, and the contract should reflect that from the day it is signed.
If you are preparing to outsource an app and want the requirements, milestones and handover terms reviewed before you commit, Linestech can go through them with you.
Frequently asked questions
Who should own the Apple and Google developer accounts?
Your business, always. Open them in your company name before development begins and add the vendor as a team member with the access they need. If an app is published under a vendor's personal account, you cannot easily transfer the listing, its reviews or its install base, and you cannot ship updates without their cooperation.
How long does it take to outsource and launch an app in Nigeria?
For a simple MVP, roughly three to four months from kick-off to live, including discovery, design, build, testing and store review. A medium business app typically takes five to eight months. Add two to four weeks specifically for store submission and possible resubmission, which buyers routinely leave out of their plans.
What happens if the store rejects our app?
Rejection is common and usually fixable within days. The store gives a reason — often a privacy declaration, a missing account deletion route, an unjustified permission or incomplete reviewer credentials. Your contract should state that the vendor addresses rejections within the agreed price, rather than treating each resubmission as extra work.
Can we outsource the app but keep the backend in-house?
Yes, and it is a reasonable split if you have backend capability, because the backend is the long-lived, data-sensitive part. Define the API contract early, agree who tests integration points, and name one party accountable for the app working end to end so that neither side waits for the other.
How much should we hold back until handover?
A final milestone of 10–15%, released after the app is live in both stores, the handover pack is delivered and a short warranty period has begun, is a reasonable structure. It keeps attention on the unglamorous final tasks — documentation, credentials, training — that are otherwise easy to postpone indefinitely.
Should the same vendor maintain the app after launch?
Usually yes for the first year, because they know the codebase and can respond fastest. Make it a written agreement with response times and included hours rather than an informal understanding. Review it annually, and keep the code, keys and accounts under your control so switching remains a practical option.
What is in a proper app handover pack?
Source code in a repository you own with full history, backend and database access, the admin dashboard credentials, signing and release credentials or confirmation of where they sit, third-party service accounts, environment configuration, a written architecture and deployment document, an administrator guide, design files and a recorded training session.
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.


