How to Manage an App Development Project in Nigeria

An app project is harder to manage than a website project for three reasons: the work is invisible for longer, it involves at least three moving parts (the app, the backend and the admin dashboard), and you cannot simply "fix it after launch" because users must download an update and two app stores stand between you and your fix.

None of that requires you to become technical. It requires you to insist on seeing the software running on a phone, early and repeatedly, and to control scope with more discipline than a website project needs.

Why an app project is managed differently

Four differences change how you should run the project.

• You are commissioning three systems, not one. A customer app, the backend API and database that serves it, and an admin dashboard your staff use. A quote that only describes screens is incomplete.
• Two platforms, many devices. Android and iOS behave differently, and Nigerian users span a wide range of Android devices, screen sizes and OS versions. Testing on the founder's iPhone proves very little.
• Releases are gated. Apple and Google review submissions. A fix you approve on Friday may not reach users until the following week.
• Feedback arrives late and publicly. Bugs that survive to launch appear as one-star store reviews, which are visible to every future user.

The practical consequence: front-load testing, keep the first release small, and plan the release calendar rather than improvising it.

The phases of an app project and what you sign off

Indicative proportions only; they shift with scope and team size. A simple MVP commonly runs 8–16 weeks; a medium app with accounts, payments, notifications and an admin dashboard commonly runs 16–28 weeks; complex marketplace or fintech products run longer.

Insist on a clickable prototype at the design stage. Walking through the prototype on your phone for twenty minutes will reveal more scope problems than reading a 30-page requirements document.

Fixing the MVP scope, and keeping it fixed

The most expensive mistake in Nigerian app projects is building version three before shipping version one. Scope discipline is your main lever on both cost and timeline.

Use a three-column split at kick-off:

Rules that keep the split honest:

1. If removing a feature still leaves an app a customer would use, it belongs in Release 2.
2. Every feature must have an owner who can say what happens in the failure case, not only the happy path.
3. New ideas go to the backlog with a written cost and time estimate before anyone starts building.
4. Review the backlog fortnightly and move items consciously, with the sponsor present.

A practical benchmark: an indicative ₦4,000,000 MVP that ships in four months and gets real users is worth more than an indicative ₦12,000,000 platform that is still 80% done after a year.

Roles, governance and the two-week rhythm

• Product owner (your side). One person who prioritises the backlog, answers questions within 24–48 hours and accepts each iteration. Without this role, the project drifts.
• Sponsor. Approves budget and major scope changes; reviews monthly.
• Operations representative. The person whose team will use the admin dashboard daily.
• Beta coordinator. Recruits and manages test users; often the same person as the product owner in a small business.
• Vendor project manager and tech lead. Your counterparts.

The rhythm that works for most Nigerian SME app projects:

1. Two-week iterations, each ending with a demonstration and a new test build.
2. A 30-minute demo call at the end of each iteration, where you install and use the build, not watch a screen share.
3. A written iteration report: completed, planned next, blocked on client, open risks, budget consumed.
4. A fortnightly backlog review with the sponsor for anything that changes cost.
5. A shared issue tracker — even a well-maintained spreadsheet works — with severity levels and owners.

How to verify progress: get the build onto your phone

Ask for an installable build from the first or second iteration. This is the single most effective control you have.

• Android: an APK file or an internal testing track on Google Play.
• iOS: TestFlight, which requires an Apple Developer Program account (historically US$99 per year; confirm the current fee with Apple).

What to check on each build, beyond whether the feature exists:

• Does it work on mobile data, not only on office Wi-Fi?
• What happens when the network drops mid-transaction?
• How long does the app take to open on a mid-range Android phone?
• How large is the download? Nigerian users abandon very large installs.
• Do error messages explain what to do, or show raw technical text?

A vendor who cannot produce an installable build until "the end" is asking you to accept several months of unverifiable progress. Treat that as a serious risk signal.

Testing and running a useful beta

Testing an app runs in three layers, and each one catches different problems.

1. Vendor QA. Their testers verify features against the specification, across a device matrix. Ask which devices and OS versions are covered, and request the test report.

2. Internal acceptance testing. Your staff run realistic end-to-end scenarios: a customer registers, orders, pays with a card that fails, retries with a transfer, cancels, and requests a refund. Write these scenarios from your actual operation, including the awkward cases.

3. Beta with real users. Recruit 15–40 people who resemble your customers, not only friends and colleagues who will be polite. Give them a specific task list and a simple feedback channel (a WhatsApp group works well and is where Nigerian testers will actually respond). Run it for one to three weeks.

Device coverage worth insisting on for the Nigerian market:

• At least three Android devices across budget, mid-range and recent flagship
• At least two Android OS versions, including an older one still in common use
• At least one small screen and one large screen
• At least two iPhones if iOS is in scope, including an older supported model
• Testing on mobile data at varying signal strength, and in aeroplane mode to check offline behaviour

Agree a defect severity scale — blocker, major, minor, cosmetic — and agree that only blockers and majors hold up release.

App store accounts, submission and review

Store logistics are routine but they consume calendar time, and they are a common source of ownership disputes.

• Open the store accounts in your company's name, not the developer's. Google Play developer registration has historically been a one-time US$25 fee and the Apple Developer Program an annual fee historically US$99; verify current fees and requirements directly with Google and Apple, as they change.
• Business verification. Both stores may request identity or organisation verification, which can take days. Start early, and have your CAC documents ready if registering as a company.
• Prepare listing assets before the app is finished: app name, short and long description, screenshots for several device sizes, an icon, a privacy policy URL and a support contact.
• Allow time for review. Submissions are reviewed and can be rejected for fixable reasons — missing privacy disclosures, broken test credentials, incomplete metadata, or account deletion requirements. Plan two to three weeks between "the app is finished" and "the app is live", and never book a launch event before the app is approved.
• Plan the update cadence. Agree with your vendor how quickly a critical bug fix can be produced, submitted and made available to users.

Ask for a written release plan covering who submits, who holds the signing keys, and how a rollback would be handled.

Milestones, payments and change control

Indicative structure only; terms vary by vendor and project size. Keep a retention and a defined warranty period, typically 30–90 days, during which defects are fixed at no cost.

For change control, require a one-page note for every request: what, why, cost, time impact, which release it belongs to, who approved. Carry a contingency of 10–15% of project value. Changes are normal on app projects, because using the product teaches you things a document cannot. The discipline is not refusing changes; it is pricing them and placing them in a release.

Launch and the first 90 days

An app is not finished at launch; it enters its operating life. Plan the first quarter before you ship.

Pre-submission checklist:

• Store accounts in the company's name, with your staff as owners
• Signing keys and keystore held by your business, backed up securely
• Privacy policy published and matching what the app actually collects
• Account deletion path available, if the app has user accounts
• Payment flows tested end to end with real low-value transactions
• Push notifications tested on both platforms
• Crash reporting and basic analytics installed and connected to your accounts
• Support channel decided, published and staffed during working hours
• Version numbering and release notes agreed
• Source code repository access transferred to your company
• Rollback plan agreed for a bad release

In the first 90 days, track four things weekly: crash-free sessions, installs versus active users, completion rate of the core action (order placed, booking made, payment completed), and the themes in store reviews and support messages. Plan at least two update releases in that period — one for defects found in real use, one for the highest-value improvement your data points to.

Budget for maintenance from day one. As an indicative planning figure, annual app maintenance commonly runs at 15–25% of the original build cost, covering OS updates, library updates, store policy changes, server costs and small improvements.

Example (hypothetical): a pharmacy chain's ordering app

Example (hypothetical). A pharmacy chain with four branches in Ibadan commissions a customer ordering app with prescription upload, delivery and card payment. Indicative budget ₦9,000,000, indicative timeline 22 weeks.

How the operations director runs it:

• Appoints herself product owner and the head pharmacist as operations representative, with a rule that all requests to the vendor come through her.
• Fixes the MVP: browse products, upload a prescription photo, pay, choose delivery or branch pickup, track status, admin dashboard for branch staff. Written as out of scope for Release 1: loyalty points, subscriptions, chat with a pharmacist, and an iOS-only widget.
• Requires an installable Android build from iteration two. The first build reveals that the prescription upload fails on photos above a certain size — a defect that would have been expensive to find in month five.
• Runs a three-week beta with 25 regular customers recruited in-store, coordinated in a WhatsApp group. The strongest finding is not a bug: customers assumed delivery was free and abandoned checkout when the fee appeared late. The fee is moved to the product page.
• Opens the Google Play and Apple accounts in the company's name in week four, because business verification took eight working days.
• Approves one change during the build — branch-level stock visibility, quoted at an indicative ₦700,000 — and defers loyalty points to Release 2.
• Holds back 10% of the fee for 60 days after launch, and books two update releases into the calendar for weeks four and ten post-launch.

What changes for Nigerian businesses

• Android dominates, and older devices matter. Optimise for mid-range Android first. An app that only performs well on a recent flagship will frustrate most of your users.
• App size and data cost affect installs. Users on metered data hesitate over large downloads and heavy in-app media. Ask your vendor for an app-size target and image optimisation.
• Connectivity is inconsistent. Test what happens when the network drops during payment or upload. Offline tolerance, retry logic and clear status messages are not luxuries.
• Payments are local. Card, bank transfer, USSD and wallet flows through providers such as Paystack, Flutterwave, Interswitch, Moniepoint or OPay behave differently in-app than on the web. Test each enabled method with a real low-value transaction, including a deliberate failure and a refund.
• WhatsApp is the support channel users expect. Many Nigerian users will contact you there rather than through in-app support. Decide who answers and how quickly.
• Delivery realities. If your app promises delivery, the status updates must reflect how your riders or logistics partners actually work, including failed deliveries and rescheduling.
• Data protection. Apps that collect personal data fall under the Nigeria Data Protection Act 2023; both stores also require an accurate privacy policy and data-safety declaration. Confirm your obligations with a qualified professional and the Nigeria Data Protection Commission's published guidance.
• US dollar running costs. Cloud hosting, push notification services, SMS and map APIs are typically billed in dollars. Ask for recurring costs to be listed separately, and review them when the exchange rate moves.

Mistakes to avoid

• Accepting screenshots instead of builds. If you cannot install it, you cannot verify it.
• Building for both platforms when one would do. Launching on Android first is a legitimate and cost-saving decision for many Nigerian consumer apps.
• Letting the vendor open the store accounts. Your business should own the listings, keys and reviews.
• Approving scope additions without a release decision. Every yes moves your launch date.
• Testing only with staff and friends. They know the intended path and will not find what real users find.
• Booking marketing before store approval. Review outcomes are not guaranteed to a date.
• No crash reporting at launch. You will be relying on users to describe bugs they cannot reproduce.
• Ignoring the admin dashboard. If your staff cannot operate the app's backend easily, the customer experience degrades within weeks.
• Treating the launch budget as the total budget. Maintenance, store fees, hosting and updates are ongoing.

Conclusion

Managing an app project comes down to visibility and restraint. Visibility means an installable build on your own phone every two weeks, a real beta with real customers, and crash reporting live from day one. Restraint means a written MVP scope, a backlog rather than an ever-growing build, and changes that are priced and assigned to a release. Add milestone payments tied to accepted builds, store accounts and signing keys in your company's name, and a maintenance budget agreed before launch, and most of the ways app projects fail are closed off.

If you are preparing to commission an app and want the MVP scope, release plan and handover terms defined before development starts, Linestech can help you shape the product definition and project structure first.

Frequently asked questions

How long should an app project take?

A simple MVP commonly runs 8–16 weeks, a medium app with accounts, payments, notifications and an admin dashboard 16–28 weeks, and a complex marketplace or fintech product considerably longer. Timelines depend heavily on how quickly you answer questions and approve designs. Very short quoted timelines on complex scope usually mean testing has been underestimated.

Should I build Android and iOS at the same time?

If budget is constrained, launching on Android first is often the sensible choice for a consumer product in Nigeria, then adding iOS once the product is proven. Cross-platform frameworks such as Flutter or React Native let one codebase serve both, which reduces cost but does not remove the need to test and release on each store separately.

How do I know the developer is actually making progress?

Install the build yourself every two weeks. Working software on your phone is the only progress report that cannot be exaggerated. Supplement it with a written iteration report and an issue tracker showing defects opening and closing.

What if the app is rejected by the app store?

Rejection is common and usually fixable. The store gives a reason: missing privacy information, an account deletion requirement, broken demo credentials, misleading metadata or a crash on review. Your vendor should fix and resubmit, and your contract should make store approval part of the launch milestone so the responsibility is clear.

How many beta testers do I need?

For an SME product, 15–40 testers who match your real customer profile is usually enough to surface the important issues. Quality of recruitment matters more than quantity: people who will genuinely try to complete a purchase or booking are worth far more than a large group who install the app and never open it again.

Who should hold the app signing keys?

Your business. Losing the Android signing key can prevent you from updating your own published app, and a developer holding the keys holds real leverage. Require the keys and store account ownership to be transferred to you as part of the handover milestone, with a secure backup.

How much should I keep aside after launch?

Plan for annual maintenance at an indicative 15–25% of the build cost, plus recurring hosting, store fees and third-party services. Also hold a small improvement budget for the first quarter: real usage almost always reveals one or two changes that meaningfully improve completion rates.

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)
• Paystack developer documentation
• Flutterwave developer documentation
• Apple Developer Program
• Google Play Console
• Firebase documentation