Mobile App Requirements Checklist for Nigerian Businesses (What to Write Before You Ask for Quotes)

Most app projects that go wrong in Nigeria go wrong before a line of code is written. The business describes the app in a WhatsApp voice note or a two-paragraph email, three developers interpret it three ways, the cheapest quote wins, and six months later the founder discovers that "payments" did not include bank transfer, "admin" was a database login and "iOS" was never in scope.

A requirements document fixes this. It is not a technical specification; it is a plain-language description of what the app must do, for whom, under what constraints, and how you will know it is finished. This checklist walks through each section with the questions to answer and the Nigerian specifics that developers need to know. It focuses on the document itself; Mobile App Feature ChecklistApp Development Checklist for Nigerian Businesses covers the wider procurement process.

Why a requirements document saves money

A requirements document saves money because it converts an idea into a scope that can be quoted, built and tested against. Without it, every developer quotes a different app, the build drifts as new ideas arrive, and disputes over what was "included" have nothing to refer to. With it, quotes are comparable, change requests are visible and priced, and acceptance is a checklist rather than an argument.

Practical benefits for a Nigerian business:

• Two or three quotes on the same document can be compared line by line.
• Scope creep becomes a written change request with a cost, not a favour.
• The developer can estimate integrations (Paystack, WhatsApp, SMS) accurately instead of guessing.
• Testing and acceptance have a reference: the app is done when the document's criteria are met.
• The document becomes the basis of the contract's scope schedule. What Should Be Included in an App Development Contract?.

How detailed should it be?

Match the depth to the budget and the risk. A ₦2,000,000 booking app does not need a forty-page specification; a ₦20,000,000 fintech app does.

The document does not need diagrams to be useful, but a few hand-drawn screen sketches or a simple flow diagram help enormously. Developers can produce proper wireframes during discovery.

The thirteen-section requirements checklist

Work through each section in order. Tick items as you complete them; leave a note where you genuinely do not know, because "we need the developer's advice here" is a valid answer.

1. Business context and goals

• One paragraph on what the business does and who its customers are.
• The problem the app solves, stated in business terms (missed orders, manual reconciliation, no-shows, slow support).
• The two or three measurable outcomes you expect (orders through the app, fewer support calls, faster payments).
• How the app fits with existing channels: website, WhatsApp, Instagram, physical shop.
• What already exists: current systems, spreadsheets, a website, an old app.

2. Users and roles

• Every type of user, including staff (customer, rider, agent, cashier, manager, admin, super-admin).
• For each role: what they can see and do, and what they must not see.
• Rough numbers: how many customers in year one, how many staff users.
• Device reality per role: customers on mid-range Android, managers on iPhone, field staff on old phones.

3. User journeys

• The five to ten most important journeys, written as steps: "Customer opens app, searches product, adds to cart, pays by transfer, receives receipt and delivery updates."
• The happy path and the common failure paths (payment fails, network drops, item out of stock).
• Where a human takes over (WhatsApp handoff, call from rider, manual approval).

4. Features by priority

• Must-have for launch (the app is useless without these).
• Should-have (important, could follow within weeks of launch).
• Could-have (nice, if budget allows).
• Explicitly out of scope for this version.
• For each must-have feature, one or two sentences on how it should behave.

Use Mobile App Feature Checklist.

5. Platforms and devices

• Android, iOS or both; and whether a web version is needed for staff or customers.
• Minimum Android version and the low-end devices the app must work on.
• Tablet support, if any.
• Offline expectations: which screens must work without a connection and sync later.
• Preference, if any, for native or cross-platform development (or ask the developer to recommend).

6. Integrations

• Payments: which gateway (Paystack, Flutterwave, Monnify or other), which methods (card, transfer, USSD), refunds, receipts.
• Messaging: SMS OTP provider, email, WhatsApp Business Platform for notifications.
• Maps and location, if relevant.
• Social login (Google, Apple), if relevant.
• Existing systems: accounting, inventory, CRM, school or hospital software, with a note on whether each has an API.
• Delivery or logistics partners, if relevant.
• Any AI features (chat assistant, recommendations) and where the data for them comes from.

7. Admin dashboard and reporting

• Who uses the admin dashboard and on what device (usually a web browser on a laptop).
• What staff must be able to manage: users, products, orders, bookings, content, notices, prices, promotions.
• Reports needed: daily sales, payments reconciliation, active users, tickets, whatever runs the business.
• Exports: CSV or Excel, and for which data.
• Roles and permissions within the admin.

8. Non-functional requirements

• Expected load: users per day, peak times (salary week, festive season, resumption).
• Performance targets in plain language (screens load in under three seconds on 3G).
• App size and data usage limits, given Nigerian data costs.
• Battery behaviour for apps that run in the background (delivery, tracking).
• Availability expectations and what happens during maintenance.
• Security expectations: encryption, secure login, session timeouts, protection against common attacks.
• Accessibility basics: readable text sizes, contrast, simple language.

9. Data protection and compliance

• What personal data the app collects, why, and how long it is kept.
• Privacy notice and consent requirements under the Nigeria Data Protection Act 2023.
• Where data is hosted and whether any is sent abroad (payment, AI or analytics providers).
• Sector rules: health data, financial data, children's data, e-hailing regulation, as relevant.
• Who in the business is responsible for data protection.
• Note: confirm obligations with the NDPC or a qualified adviser; the document records requirements, not legal advice.

10. Content, branding and assets

• Logo, colours and fonts, or a note that design is part of the project.
• Who writes the app's text, product descriptions, FAQs and legal pages.
• Languages: English only, or Pidgin, Hausa, Yoruba or Igbo versions.
• Images and product photography: who supplies them and in what format.
• App name, store listing text and screenshots: who prepares them.

11. Acceptance criteria and testing

• For each must-have feature, how you will confirm it works ("a customer can pay ₦5,000 by transfer and see a receipt within two minutes").
• Devices and networks the app will be tested on.
• Who from the business will test, and when.
• Beta or pilot plan: which customers or branch, for how long.
• Definition of "launched": both stores live, payments in live mode, admin trained.

Mobile App Testing Checklist.

12. Timeline, budget and phases

• Target launch date and any hard deadlines (school resumption, festive season, funding milestone).
• Budget range for the build, stated honestly so developers can propose a fitting scope.
• Budget for running costs: hosting, SMS, gateway fees, maintenance.
• Phase one versus phase two, so the developer quotes the right thing now.
• Availability of your team for meetings, content and testing.

13. Ownership, maintenance and support

• Ownership of source code, design files, app store accounts, domain and hosting accounts.
• Expected warranty period after launch for bug fixes.
• Maintenance retainer expectations and response times.
• Handover requirements: documentation, credentials, training.
• What happens if you change developer later.

Who Owns the Code After App Development?.

What changes for Nigerian businesses

Writing app requirements in Nigeria means stating things a developer overseas would never think to ask: whether bank transfer must be a payment method, whether WhatsApp is part of the customer journey, which low-end Android phones the app must run on, how the app behaves when data or power is unreliable, and what the Nigeria Data Protection Act requires. Leaving these out is the most common source of gaps between the quote and the need.

Nigerian specifics to state explicitly:

• Payment methods: transfer, USSD and POS realities, not just cards. Say whether cash on delivery is allowed and how it is recorded.
• WhatsApp: whether customers can reach support on WhatsApp from the app, whether notifications go out on WhatsApp, and whether orders that start on WhatsApp must be recorded in the app.
• Phone numbers: Nigerian formats, OTP by SMS, and what happens when SMS is delayed.
• Devices and data: the cheapest phone the app must support, and a target for app size and data usage.
• Connectivity: which actions must work offline and sync later, especially for field staff.
• Addresses and delivery: landmark-based addresses, delivery zones, Lagos traffic and time windows.
• Identity and verification: whether BVN, NIN or ID uploads are needed, and the compliance implications.
• Business registration: CAC details and, where relevant, sector licences that stores or payment providers may ask for.
• Exchange-rate exposure: which services will be billed in US dollars, so the running budget can include a buffer.

Example (hypothetical): requirements excerpt for a pharmacy chain app

Example (hypothetical): a pharmacy chain with six branches in Abuja wants an app for customers to order medicines, upload prescriptions and choose pickup or delivery. An excerpt from its requirements document might read:

Goals: Reduce WhatsApp order handling time; make prescription orders traceable; grow repeat orders for chronic medication.

Users: Customer (Android and iOS); Pharmacist (web admin, approves prescription orders); Rider (Android, delivery updates); Manager (web admin, reports).

Must-have features: Product catalogue with branch stock; prescription photo upload; pharmacist approval step before payment for prescription items; payment by card, transfer to virtual account or pay on pickup; pickup slot or delivery within Abuja zones; order status notifications by push and WhatsApp; refill reminders for repeat medication.

Out of scope for version one: Telepharmacy consultations; loyalty points; branch-to-branch stock transfer.

Integrations: Payment gateway with virtual accounts; WhatsApp Business Platform for order updates; SMS OTP; the chain's existing inventory software, which exports a daily stock file (no API).

Non-functional: Must run on Android 9 and above and on entry-level devices; product images compressed; catalogue browsable on 3G; prescription images stored encrypted and deleted 90 days after order completion.

Data protection: Prescription uploads are health data; privacy notice and consent at upload; pharmacist-only access; NDPC obligations to be confirmed by the business.

Acceptance criteria (sample): A customer can upload a prescription, a pharmacist can approve it from the web admin, the customer receives a payment request and pays by transfer, and the order appears in the rider app with a delivery address, all within one test session on a mid-range Android phone.

Ownership: Source code, design files and store accounts belong to the pharmacy chain; developer provides 60 days of bug-fix warranty and a monthly maintenance retainer quote.

That excerpt is enough for three developers to quote the same app.

How to use the document with developers

1. Send the same document to two or three developers and ask each for a written quote against it, with anything they would change or add.
2. Expect questions. Good developers will challenge the document; that is discovery, and it improves the scope.
3. Update the document after discovery and make the final version the scope schedule of the contract.
4. Keep it alive. Record every agreed change as a dated amendment with its cost and timeline impact.
5. Use it for acceptance. Test against section 11; sign off when the criteria are met.
6. Hand it over at the end with the code and documentation, so a future developer can understand the app.

Mistakes that make requirements documents useless

• Describing solutions instead of needs. "Use Firebase" is a solution; "customers must receive order updates within a minute" is a requirement. Let the developer choose tools unless you have a real constraint.
• Listing every feature as must-have. If everything is essential, the developer quotes the full product and the budget breaks. Prioritise honestly.
• Leaving out staff users. The admin side is where the business runs; a document that only describes the customer app under-scopes the project.
• Silence on payments. "Payments" means nothing; name methods, gateway, refunds and reconciliation.
• No acceptance criteria. Without them, "done" is a negotiation.
• Hiding the budget. Developers cannot propose a fitting scope without a range; withholding it produces mismatched quotes.
• Ignoring data protection. Retrofitting NDPA compliance is more expensive than specifying it.
• Never updating it. A document that stops matching the project stops being useful in disputes.

Conclusion

A mobile app requirements document is the cheapest part of an app project and the one with the highest return. Cover the thirteen sections in this checklist, state the Nigerian specifics that overseas templates miss, prioritise features honestly, include acceptance criteria and ownership terms, and send the same document to every developer you ask to quote. The app you get will be the app you described, and the quotes you compare will be for the same thing.

If you would like a second pair of eyes on your requirements before you request quotes, or a structured discovery session to turn an idea into a document developers can price, Linestech can help you define the scope of your mobile app before you commit to a build.

Frequently asked questions

Do I need a requirements document for a small app?

Yes, but a short one. Even a two-page document with goals, users, a prioritised feature list, platforms, integrations and acceptance criteria will make quotes comparable and reduce misunderstandings. The cost of writing it is an afternoon; the cost of not writing it is often a rebuild.

Should the developer write the requirements document instead?

The business should write the first version because only it knows the goals, customers and workflows. Developers then refine it during discovery, adding technical detail, flows and estimates. Some agencies offer a paid discovery phase that produces the final document; that is worth considering for complex projects.

What is the difference between requirements and a technical specification?

Requirements describe what the app must do and why, in business language. A technical specification describes how it will be built: architecture, database design, APIs, frameworks. The business owns the requirements; the developer produces the specification from them.

How do I write acceptance criteria if I am not technical?

Describe a real scenario and the observable result: "A customer in Ibadan can book a 10am slot, pay ₦3,000 by USSD, and receive an SMS confirmation within two minutes." If you can perform the scenario on a test phone and see the result, the criterion is met. Write one or two per must-have feature.

Should the document include a budget?

State a range. It lets developers propose a scope that fits and flags early if your expectations and the market are far apart. Indicative Nigerian ranges for common app types are covered in How Much Does App Development Cost in Nigeria?

How do I handle features I am unsure about?

Put them in "should-have" or "could-have", or list them as open questions for discovery. Uncertainty stated clearly is far better than a confident requirement that later changes.

Can I use this checklist for a web app or software project?

Most sections apply to any software project. For a broader treatment aimed at business software rather than mobile apps, see How to Create a Software Requirements Document.

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
• WhatsApp Business Platform — Meta for Developers