1. Home
  2. Blog
  3. Mobile App Development
  4. How to Test an App Idea Before Spending Millions

How to Test an App Idea Before Spending Millions

African business colleagues planning in an office — how to test an app idea

There is a specific kind of regret common among Nigerian founders: paying ₦4,000,000 for an app, launching it to a burst of Instagram congratulations, and watching downloads go quiet within a month. The app worked. The idea did not. Nothing in the build process was designed to find that out, because build processes test whether software works, not whether anyone wants it.

Testing an app idea is about spending small amounts of money to buy information before you spend large amounts to buy software. This article is the practical companion to idea validation: rather than the overall framework, it gives you the actual experiments, what each one costs in Nigeria, what a pass looks like, and how to sequence them so that every naira you spend is justified by the result of the previous test.

Why "just build it and see" is the most expensive test

Building the app is a test of the idea, but it is the slowest and dearest one available. A medium-complexity app with accounts, payments and an admin dashboard typically costs ₦5,000,000–₦15,000,000 to build in Nigeria (indicative 2026 range), takes three to six months, and then needs money to acquire users before it produces any evidence at all. If the evidence is negative, you have paid the maximum price for the answer.

Every experiment below produces a weaker version of the same evidence at a fraction of the cost and time. Weak evidence obtained in two weeks for ₦30,000 is worth more than strong evidence obtained in six months for ₦8,000,000, because the cheap evidence tells you whether to spend the expensive money at all.

The key principle: you are buying information, and information gets more expensive as you go up the ladder. Buy the cheap information first.

The staged spending ladder

Think of testing as a series of gates. You only pass through a gate when the previous experiment hits its pass mark.

StageExperimentWhat it testsIndicative cost (2026)Time
0Problem interviewsIs the problem real?₦0–₦30,0001–3 weeks
1Fake-door testWill strangers show interest?₦0–₦50,0001–2 weeks
2Concierge serviceWill people use a manual version and come back?₦0–₦100,0002–6 weeks
3Wizard-of-Oz testDoes the experience work when it looks automated?₦20,000–₦150,0002–4 weeks
4Clickable prototypeDo users understand and want the product as designed?₦50,000–₦300,0001–3 weeks
5Pre-sale or paid pilotWill people pay before it exists?Payment gateway fees only2–6 weeks
6No-code or single-feature MVPDoes the core loop work in software?₦300,000–₦2,000,0004–8 weeks
7Lean coded MVPCan it scale beyond manual effort?₦1,500,000–₦5,000,000+2–4 months

All figures are indicative and vary with scope, vendor and exchange rate. Not every idea needs every stage. A simple consumer service might go from concierge straight to a lean MVP. A complex B2B tool might need a prototype and a paid pilot before any code. The point is to never skip from Stage 0 to Stage 7.

Experiment 1: The fake-door test

A fake-door test presents the app as if it exists and measures how many people try to "open the door". It is the cheapest way to check whether strangers, not friends, respond to the idea.

How to run it in Nigeria

  • Create a one-page landing page or a well-designed Instagram profile describing the app and its main benefit, with a clear button: "Download", "Join", "Book now".
  • The button leads to a short form: "We are launching soon. Leave your WhatsApp number to be first."
  • Drive a small amount of traffic: ₦10,000–₦40,000 of targeted Instagram or Facebook ads aimed at your exact customer profile in your launch city, plus shares in relevant WhatsApp and community groups.
  • Measure: how many people saw it, how many clicked, how many left a number.

What a pass looks like

There is no universal benchmark, so set yours in advance. A reasonable approach: if fewer than 2 in 100 visitors leave a number, the message or the idea is weak; if more than 10 in 100 do, interest is strong. Treat these as your own thresholds, not industry statistics.

Ethics note

Tell people clearly that the app is coming and do not take money at this stage. Collect only the data you need (a name and a WhatsApp number is enough) and handle it in line with the Nigeria Data Protection Act 2023; people who trust you with a number expect not to be spammed.

Experiment 2: The concierge service

A concierge test delivers the app's outcome by hand. You become the app. For most Nigerian consumer and SME ideas, this means a WhatsApp Business number, a catalogue or price list, and manual fulfilment.

Why it is the most valuable test for Nigerian ideas

  • It is how many successful local services actually began.
  • It generates revenue, so it can fund the next stage.
  • It reveals operational problems (delivery delays, payment confirmation, customer no-shows) that an app cannot fix and a founder must understand.
  • It produces a list of real customers you can interview and invite to test the software later.

How to run it

  1. Take the people from your fake-door list and offer them the service manually.
  2. Fulfil every order yourself for two to six weeks. Do not automate anything.
  3. Track each order in a spreadsheet: who, what, how they paid, how long it took, what went wrong, whether they came back.
  4. Ask every customer one question after the second order: "What would make you stop using this?"

What a pass looks like

Repeat usage. Anyone can order once out of curiosity. If a meaningful share of customers order a second and third time within the test period, you have a habit forming. If almost nobody returns, the idea is a one-time novelty, and an app will not change that.

Experiment 3: The Wizard-of-Oz test

A Wizard-of-Oz test looks automated to the customer but is powered by a person behind the scenes. It is the concierge test with a thin layer of software on top, and it is useful when the idea depends on the feeling of automation, for example an AI recommendation, an instant quote or an automatic match.

Example set-ups

  • A WhatsApp number where a person replies within one minute using a script, to simulate a chatbot.
  • A form that "instantly" generates a quote, where the founder receives the submission and replies by email within minutes.
  • A "matching" service where the match is made by hand from a spreadsheet.

What it tests

Whether customers value the outcome enough when it appears effortless, and whether the response time and quality you can deliver by hand is good enough. If customers are satisfied with the manual version behind the curtain, software will only make it cheaper. If they are dissatisfied even with a human doing the work carefully, the problem is the idea, not the technology.

Experiment 4: The clickable prototype

A clickable prototype is a set of designed screens linked together so that a user can tap through the app as though it existed. It contains no working code. Design tools make this affordable: a freelance UI designer in Nigeria may produce a 10–15 screen prototype for roughly ₦50,000–₦300,000 (indicative), or a founder can build a rough version themselves.

When it earns its place

  • The product is complex and hard to explain in words (multi-step booking, dashboards, financial tools).
  • You need to test whether users understand the flow before paying developers to build it.
  • You are raising money or recruiting a technical co-founder and need something tangible.

How to test with it

Sit with five to eight target users, one at a time, in person or on a video call. Give them a task ("book a delivery for tomorrow morning") and watch silently. Note where they hesitate, misunderstand or give up. Five sessions usually reveal the major problems. Fix them and test again before any code is written.

What it does not test

Demand. A prototype tests comprehension and design, not whether anyone will pay. Do not treat positive prototype feedback as validation of the business.

Experiment 5: The pre-sale or paid pilot

The pre-sale asks customers to pay before the product exists. For consumer apps, this might be a discounted lifetime or annual plan; for B2B tools, a paid pilot with two or three companies. Money is the strongest signal available, and Nigerian gateways such as Paystack or Flutterwave make it simple to create a payment link.

Running it responsibly

  • State plainly what the customer is buying, when it will be delivered and how refunds work.
  • Keep the amount modest (for example ₦2,000–₦10,000 for consumers) and keep the money separate until you deliver.
  • If you cancel the project, refund promptly and in full. Your reputation in a WhatsApp-connected market is worth more than the deposits.

What a pass looks like

Set a target number of paying customers before launching the pre-sale, based on what you would need to justify the build. If you set "30 paying pre-orders" and get 6, the answer is clear and cheap. If you get 60, you have both evidence and part of your build budget.

Experiment 6: The no-code or single-feature MVP

Before a full coded MVP, consider a version built with no-code tools or a single-feature app. A booking idea can be tested with a form builder and a payment link; a marketplace can be tested with a simple web listing page and WhatsApp for transactions; an internal tool can be tested with a spreadsheet and a workflow-automation service.

This stage typically costs ₦300,000–₦2,000,000 (indicative) depending on whether you use tools yourself or hire help. It tests whether the core loop works in software and whether customers behave the same way when a human is no longer fulfilling every step. It is also the stage where Nigerian constraints such as slow connections, payment confirmation delays and low-end Android devices start showing up in the data.

If the no-code version strains under real usage or hits a wall on features customers need, that is your signal to move to a properly coded MVP with a clear, evidence-based scope.

Setting pass marks before you run a test

The single most important discipline in testing is deciding what "pass" means before you see the results. Founders who decide afterwards always pass.

Use a simple written test card for each experiment:

  • Hypothesis: what you believe (for example, "small fashion vendors in Aba will pay ₦5,000 a month for order management").
  • Test: what you will do and for how long.
  • Metric: the single number you will measure.
  • Pass mark: the value that means "proceed".
  • Fail action: what you will do if it fails (pivot the customer, pivot the price, pivot the feature, or stop).

Write the card, share it with someone who will hold you to it, and then run the test. When it is done, compare the metric to the pass mark in writing. This is the difference between testing and hoping.

What changes when you test ideas in Nigeria

  • Your cheapest test environment is WhatsApp. Almost every experiment above can be run with a WhatsApp Business number before any web or app work. Use it.
  • Paid traffic is affordable but noisy. Small Instagram and Facebook campaigns are cheap enough to fund a fake-door test, but audiences outside major cities can be thin, and click quality varies. Combine paid traffic with community groups and referrals.
  • Trust is the hidden variable. Payment drop-off in Nigeria is often a trust problem, not a price problem. In any test involving money, offer a visible way to verify you are real: a CAC registration, a physical address, a consistent brand across channels, and a human who answers.
  • Cash-on-delivery behaviour will appear. Expect a share of customers to refuse to pay upfront in early tests. Record it; it tells you whether your app must support pay-on-delivery or escrow-style flows, which affects build cost.
  • Data collection has legal weight. Names, phone numbers and location data gathered during tests are personal data under the NDPA 2023. Collect the minimum, store it sensibly and delete it when the test ends if you have no further legitimate use. Consult the NDPC guidance or a professional if unsure.
  • Power and connectivity affect your metrics. A test that runs during a period of poor network in your target area will under-report demand. Note conditions when interpreting results.
  • Exchange rate affects tool costs. No-code tools, ad platforms and prototyping software are largely priced in USD. Budget in naira with a margin, and reconsider tools whose monthly cost would not survive a rate change.

Example (hypothetical): testing a laundry pickup app in Lagos

This is a hypothetical example to illustrate the ladder; it does not describe a real business or a Linestech client.

A founder in Yaba believes busy professionals will pay for scheduled laundry pickup and delivery via an app.

  • Fake-door test (12 days, ₦25,000 in ads plus group shares): A single landing page and an Instagram profile. 410 visitors, 37 left WhatsApp numbers. Pass mark had been set at 20. Proceed.
  • Concierge service (5 weeks, ₦60,000 in rider costs and packaging): The founder partners with a local laundry, takes bookings on WhatsApp and dispatches a rider. 29 customers, 68 orders; 17 customers ordered at least twice. Pass mark: 12 repeat customers. Proceed. Two operational lessons: pickups must be scheduled in evening windows, and customers insist on itemised receipts because of lost-item disputes.
  • Pre-sale (3 weeks): A ₦5,000 "founder plan" giving a discount on the first month once the app launches. Pass mark: 25 paying customers. Result: 14. Fail.
  • Fail action: The founder interviews the people who declined. Most say they like the service but see no reason to pay in advance for an app when WhatsApp works. The pivot is not to abandon the idea but to change the form: keep the WhatsApp-based service, build a lightweight web app for scheduling and receipts (which solves the two operational lessons), and revisit a full mobile app only if the customer base outgrows manual dispatch.

The founder spent roughly ₦100,000 and eight weeks to learn something that a ₦5,000,000 app would have taught them in eight months.

Mistakes that waste test budgets

  • Testing several assumptions at once. If the fake-door test changes the price, the audience and the message simultaneously, a failure tells you nothing. Change one variable per test.
  • Running tests without a pass mark. Covered above; it is the most common error and the easiest to fix.
  • Over-investing in the prototype. Polished, animated prototypes flatter the founder but test only comprehension. Rough screens tested with real users are more useful.
  • Testing with the wrong audience. Friends, tech Twitter and your own WhatsApp contacts are not your market unless your market is literally them.
  • Ignoring operational findings. The concierge test often reveals that the hard part is delivery, supply or trust, not software. Founders sometimes proceed to build anyway, automating around a problem the app cannot solve.
  • Confusing activity with evidence. Three hundred Instagram followers, a nice logo and a domain name are not test results.
  • Stopping the manual service when the build starts. Keep it running. It is your revenue, your feedback loop and your first hundred users.
  • Skipping regulatory checks for regulated ideas. If the idea involves lending, payments, health records or transport, confirm licensing requirements with the relevant authority before spending on any test that takes money.

Conclusion

Testing an app idea is a sequence of increasingly expensive questions, and the discipline is to ask the cheap ones first: does anyone show interest, does anyone use a manual version twice, does anyone pay before it exists, does the core loop hold up in simple software. Set a pass mark for every test before you run it, act on failures instead of explaining them away, and keep the manual version running as your first business. Founders who work this way rarely spend millions on an app nobody wanted, and when they do build, the scope is small, specific and already paid for by customers.

When your tests pass and it is time for software, Linestech can help you turn the evidence into a tightly scoped MVP, choosing the build approach that fits what your customers actually showed you. Bring your test results and we can plan the smallest version worth building.

Frequently asked questions

How much should I spend testing an app idea before building?

A reasonable rule of thumb is to spend no more than a small fraction of your intended build budget on tests, often ₦50,000–₦500,000 in total across several experiments, and to release each tranche only when the previous test passes. If a test needs more than that to produce a signal, the idea may be one that cannot be tested cheaply, which is itself worth knowing.

What is the difference between a prototype and an MVP?

A prototype is a set of designed screens with no working functionality, used to test whether people understand and like the flow. An MVP is working software that delivers the core outcome to real users, used to test whether people adopt and pay. Prototypes cost tens of thousands of naira; MVPs typically cost millions.

Can I test an app idea using only WhatsApp?

For many consumer and SME ideas, yes. A WhatsApp Business number can serve as the fake door (people message to "join"), the concierge channel (you fulfil orders manually) and the pre-sale channel (you send a payment link). The tests it cannot run are those that depend on the app's own interface, such as complex dashboards.

How do I know when to stop testing and start building?

When the pre-sale or paid pilot passes its pass mark, the concierge version is straining under manual effort, and you have a written list of the features customers actually used. Building before that point means guessing; building long after it means losing customers you could already serve better.

Is a failed test a wasted investment?

No. A failed test that cost ₦40,000 and saved a ₦6,000,000 build is one of the best returns available to a founder. It also usually produces a better idea, because you now understand the customer's real behaviour and objections.

Should I tell test customers that the service is an experiment?

Be honest about what exists. You do not need to announce "this is a test", but you must not pretend an app is live when it is not, take payments for something you cannot deliver, or collect personal data without a clear purpose. Honesty also protects your reputation, which in a referral-driven market is your main asset.

Do these tests work for B2B or enterprise app ideas?

Yes, with adjustments. Replace ad-driven fake-door tests with direct outreach to 20–30 target companies; replace the concierge service with a manually operated version of the tool for two or three pilot customers; replace consumer pre-sales with paid pilots or signed letters of intent. B2B cycles are slower, so allow more time for each stage.

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.