How to Validate an App Idea in Nigeria

Most app ideas in Nigeria fail before they fail. They fail at the point where the founder assumes that because a problem is loud, people will download an app to fix it. Loud problems and paying customers are not the same thing. Validation is the discipline of finding out which one you have, using as little money as possible.

This guide gives you a framework built for the Nigerian market: where WhatsApp is the default interface, where trust is earned slowly, where data costs shape behaviour and where "I will use it" and "I have used it" are separated by a wide gap. It is written for founders, business owners and corporate teams who have an app idea and want a disciplined answer to the question "should we build this?" before they read about how to build an MVP or what it costs.

What validating an app idea actually means

Validating an app idea means gathering real evidence that a defined group of people has a problem worth solving, will change their behaviour to use your solution, and can be reached at a cost your business model can bear. It is not asking friends whether they like the idea. It is not a survey where everyone ticks "very interested". It is a series of small experiments whose results you would be willing to lose money on.

The distinction matters because building an app in Nigeria is not cheap. Even a lean MVP typically costs between ₦1,500,000 and ₦5,000,000 (indicative 2026 range; actual quotes vary with scope and vendor), and that is before marketing, maintenance and the months of your own time. Validation is how you decide whether that money is an investment or a donation.

A useful mental model: you are trying to disprove the idea as cheaply as possible. If you genuinely try to break it and it survives, you have something. If you only look for confirmation, you will find it, and it will be worthless.

The four questions every app idea must answer

Every app idea, whether it is a consumer marketplace or an internal tool for a manufacturing company, has to survive the same four questions.

Most founders only answer the first question, and they answer it with enthusiasm rather than evidence. The second question is the one that separates ideas that become businesses from ideas that become expensive lessons. If people are not already spending something to deal with the problem, an app rarely makes them start.

Step 1: Write the idea down as a hypothesis

The first step is to convert your idea from a product description into a testable statement. A product description says "an app that connects tailors with customers". A hypothesis says who, what, why and how much.

Use this template:

• Who: Working professionals in Lagos aged 25–40 who order custom outfits at least four times a year.
• Problem: They cannot reliably find a tailor who delivers on time, and they have no recourse when the outfit is late or wrong.
• Current workaround: Personal referrals, Instagram searches, repeat use of one tailor even when unhappy.
• Proposed solution: A booking and escrow-style payment app where tailors are rated on delivery time.
• Value the customer gets: Fewer missed events, less chasing on WhatsApp, money protected until delivery.
• Willingness to pay: A service fee of roughly 5–10% on each order, paid by the customer or the tailor.
• Riskiest assumption: That customers will pay through an app instead of transferring directly to the tailor.

The last line is the important one. Every idea has one assumption that, if false, kills the whole thing. Identify it now so that your experiments target it directly instead of testing the easy parts.

Step 2: Run problem interviews the Nigerian way

Problem interviews are structured conversations with 15–30 people who match your "who" definition. The goal is to hear how they experience the problem today, not to pitch your app. In Nigeria, these interviews work best as short voice calls or in-person conversations rather than typed surveys, because people share far more when talking than when filling a form.

Who to interview

• People who match your target customer precisely, not "anyone who might use it".
• A mix of people you know and strangers reached through referrals, community groups or a small paid incentive (airtime or data is a normal and appreciated thank-you).
• If your app serves two sides (for example, vendors and buyers), interview both sides separately.

What to ask

Keep questions about the past and present, never the hypothetical future:

1. "Tell me about the last time you had to (do the thing your app addresses)."
2. "How did you handle it? What did you use?"
3. "What was the most annoying part?"
4. "What did it cost you, in money or time?"
5. "Have you tried anything else? Why did you stop?"
6. "If this went away tomorrow, what would you do?"

Do not ask "would you use an app that does X?" Nigerians are polite, and almost everyone says yes. Yes costs them nothing. Instead, listen for emotion, repetition and existing spending. If several people independently describe the same frustration in the same words, you have found something real.

How to record and score

After each interview, note three things: the strength of the pain (mild, moderate, severe), the current workaround, and any spending mentioned. After 15 interviews, if fewer than half report moderate-to-severe pain, the problem is probably not worth an app. If most do, move to Step 3.

Step 3: Test demand before you test the product

Once you know the problem is real, test whether people will act. The cheapest and most Nigerian way to do this is a manual, WhatsApp-based version of your service, sometimes called a concierge test. You deliver the outcome yourself, by hand, with no app.

Three demand tests that cost very little

Indicative 2026 costs; actual spend varies. The WhatsApp concierge test deserves special attention. It is how many Nigerian food, fashion, grocery and errand services actually started: a number, a status update, manual delivery. If you cannot get 20 strangers to order from a WhatsApp number, an app will not save the idea. If you can, you now know your unit economics, your delivery problems and your customers' objections before you write a single line of code.

For business-to-business ideas, replace the WhatsApp catalogue with a spreadsheet-based version of your software. Offer to run the process manually for three companies for a month. If they will not give you access to the problem for free, they will not pay for an app that solves it.

Step 4: Check willingness to pay, not willingness to praise

Willingness to pay is the difference between a validated idea and a popular one. Nigerian consumers are price-aware and quick to compare, so an app that people love but will not pay for (directly or through a business model that funds it) is not validated.

Ways to test willingness to pay honestly:

• Charge during the concierge test. Even a token fee changes behaviour. Watch how many people drop out when money appears.
• Ask about current spending, not future spending. "What did you spend on this last month?" is reliable. "How much would you pay?" is not.
• Offer a paid pre-launch tier. For example, ₦2,000 for early access with a founder-guaranteed refund. Count the payments, not the promises.
• For business customers, ask for a letter of intent or a pilot agreement with a nominal fee. Companies that will not sign a pilot will not sign a contract.

If your model is free-to-use with revenue from vendors, advertisers or transaction fees, then it is the payer whose willingness you must test, not the user. Many Nigerian marketplace ideas collapse here: buyers love the free service and vendors refuse the commission.

What changes when you validate in Nigeria

Validation frameworks written for the United States or Europe assume things that are not true here. Adjust for these realities:

• WhatsApp is the baseline competitor. Your app is not competing with nothing; it is competing with a free, familiar, always-open channel. Your validation must show why someone would leave WhatsApp for your app, or how your app works alongside it.
• Trust must be tested explicitly. Nigerians have good reasons to be cautious with new apps that ask for payment or personal data. Include questions about trust in interviews and expect payment drop-off in demand tests. A pattern of "I will pay on delivery" is data, not a nuisance.
• Data and device constraints shape usage. Ask what phone people use and how they buy data. An idea that needs constant connectivity or a heavy download faces a real ceiling outside the biggest cities.
• Location changes everything. Behaviour in Lagos Island differs from Ikorodu, and both differ from Kano. Validate in the specific place you intend to launch, not "Nigeria" in the abstract.
• Payment behaviour is fragmented. Bank transfer, POS, USSD and wallet payments all coexist. Watch which methods your test customers actually use; this affects both your build cost and your fraud risk.
• Regulation may apply early. Ideas touching payments, lending, health data or transport may need licences or registrations before launch. Check with the relevant regulator (for example the CBN for payment services) and a qualified professional before investing; do not assume you can "sort it out later".
• Exchange-rate exposure is a validation issue. If your app depends on USD-priced infrastructure or AI services, test whether your naira pricing can absorb that cost. An idea that is profitable at one exchange rate and loss-making at another is not validated.

Example (hypothetical): validating a pharmacy delivery app in Ibadan

This example is hypothetical and is included to show the process, not to describe any real business or Linestech client.

A founder in Ibadan wants to build an app that delivers prescription refills from registered pharmacies to homes within two hours.

Hypothesis: Adults managing chronic conditions (hypertension, diabetes) who refill monthly waste time and transport money visiting pharmacies and sometimes miss doses when they run out.

Problem interviews (20 people, three weeks): Fourteen described the monthly refill as a chore; nine had missed doses at least once due to running out; twelve already sent someone (a child, a driver, an okada rider) to buy medication, spending ₦500–₦1,500 per trip. Riskiest assumption identified: that customers will trust a delivered medicine's authenticity.

Demand test (WhatsApp concierge, one month): A WhatsApp Business number, a simple price list from two partner pharmacies, manual delivery by a hired rider. Result: 31 orders from 18 customers, 11 of whom reordered. Delivery fee of ₦700 was accepted without complaint; three customers asked for proof of the pharmacy's registration before their first order.

Willingness to pay: Customers paid the delivery fee by transfer before dispatch in 26 of 31 orders. Five insisted on paying on delivery. Partner pharmacies agreed to a small commission after seeing repeat orders.

Decision: Proceed to a lean MVP, but with two design changes drawn from validation: show the pharmacy's registration status prominently, and support pay-on-delivery for first orders. The founder also learnt that the concierge version could keep running during the build, generating revenue and customers before launch.

Notice what the founder did not do: build an app, then look for customers.

The go/no-go scorecard

After your experiments, score the idea honestly. This scorecard is a decision framework, not a formula; use it to force a clear conversation.

Scoring guide (indicative): 11–14 means build a lean MVP; 7–10 means run more targeted tests on the weak criteria; below 7 means pivot the idea or stop. The value is not in the number but in being forced to give a zero where a zero is deserved.

Mistakes that produce false validation

• Interviewing only people who like you. Friends and family validate everything. Recruit strangers.
• Asking about the future. "Would you use…" questions generate polite fiction. Ask about the past.
• Counting sign-ups as demand. A waitlist of 500 numbers means little if nobody pays. Measure the step that costs the customer something.
• Testing in the wrong location. Validating in Lekki and launching in Onitsha is testing a different market.
• Ignoring the payer. In two-sided models, founders often validate the free side and forget the side that funds the business.
• Skipping regulatory checks. Discovering a licence requirement after building is expensive. Verify early with the relevant authority.
• Falling in love with the solution. Validation may tell you the problem is real but the app is the wrong form. A WhatsApp service, a website or a simple web app may be the right answer. Be willing to hear that.
• Stopping the manual version too early. The concierge test is a business. Keep it running; it funds and informs the build.

What to do after validation

If the scorecard says build, the next steps are practical:

1. Write down what you learnt as requirements. Every design decision in the MVP should trace back to something a customer said or did. A structured requirements document keeps the build focused; see the related article on app requirements checklists.
2. Scope the smallest version that delivers the validated outcome. Not the smallest version of your vision, the smallest version customers already showed they want.
3. Decide the build route. Depending on the idea, a no-code tool, a progressive web app, a cross-platform build or a native app may be appropriate. Your validation data (device types, connectivity, payment behaviour) should drive this choice.
4. Get 2–3 [written quotations](/pricing/) on identical scope from developers or agencies, and compare them on what is included, not just on price.
5. Keep the manual service running as your first customer channel and your feedback loop.

If the scorecard says stop, that is a successful outcome. You have saved millions of naira and months of effort, and you now understand a customer group well enough to find a better idea in the same space.

Conclusion

Validating an app idea in Nigeria comes down to replacing opinions with evidence, in order of cost: interviews first, a manual demand test second, a willingness-to-pay check third, and only then a build decision. The Nigerian context adds specific tests for trust, WhatsApp as the default alternative, payment behaviour, connectivity and regulation. Run the experiments honestly, score the results without flattery, and treat a "no" as money saved.

If your idea passes validation and you want a second opinion on the smallest app worth building, Linestech works with Nigerian founders and businesses to turn validated ideas into scoped, buildable MVPs. Share what you learnt and we can help you decide what to build first.

Frequently asked questions

How many people should I interview to validate an app idea?

Fifteen to thirty interviews with people who closely match your target customer is usually enough to see clear patterns. Fewer than ten leaves too much room for coincidence; beyond thirty you tend to hear repetition. Quality matters more than quantity: ten strangers who match your customer profile are worth more than fifty acquaintances who do not.

Can I validate an app idea without any money?

Largely, yes. Problem interviews cost only time and perhaps airtime as a thank-you. A WhatsApp concierge test can run with a phone number and manual effort. The main costs appear when you pay for traffic to a landing page or hire someone to fulfil orders. Many founders validate for under ₦100,000 before deciding whether to invest millions in a build.

Should I validate with a survey or with interviews?

Interviews. Surveys in Nigeria tend to produce polite, positive answers that do not predict behaviour, and they cannot follow up on a surprising comment. Use a survey only after interviews, to check how widely an interview finding applies, and keep it short and factual (what people did, not what they would do).

How long should validation take?

Typically four to eight weeks: one to three weeks of interviews, then two to five weeks of a demand test. If your customers are businesses with slow decision cycles, allow longer. Validation that drags beyond three months without a clear signal is itself a signal.

What if competitors already have a similar app?

Existing competition is often positive evidence that the problem is real. Your validation should then focus on why customers are dissatisfied with current options and whether your difference matters enough to make them switch. Interview competitors' users specifically and ask what they would change.

Do I need a prototype to validate an idea?

Not for problem validation. For demand validation, a clickable prototype can help customers understand a complex product, but a manual service or a clear landing page often works better because it tests real behaviour rather than reactions to screens. Save the prototype for refining the design once demand is established.

Is a waitlist enough evidence to start building?

Rarely. A waitlist shows interest, not commitment. Treat it as a pool of people to interview and to invite into a concierge or pre-order test. If a meaningful share of the waitlist pays or actively uses a manual version, you have evidence. If they only signed up, you have a mailing list.

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.

• Central Bank of Nigeria (CBN)
• Google Search Central Blog
• TechCabal — African technology news
• Techpoint Africa