A minimum viable product should answer one question: will people use this product, and will they pay for it? Answering that question the wrong way gets expensive fast when talking about mobile. App Store review cycles, two platforms, device fragmentation, and push notification permissions all add weight to every guess the team carries into development.
Goodface agency runs validation as the first phase of every mobile product we build. Our product designers and strategists test the idea against real user behaviour and market demands. Founders get a build plan based on evidence, a protected budget, and a first release that does one job well.
1. The problem hurts enough to pay for
Every app idea starts with a problem, but the size of that problem decides whether the product has a future. Users often agree that something is annoying and still never change their behavior to fix it.
We test this with problem interviews. We talk to the target audience and ask everything about using the product. Skip questions like “Would you use an app that…?” because people answer them politely rather than honestly.
The strongest signal is a workaround. Listen for signs like these:
- Homemade systems — users track the problem in spreadsheets, notes apps, or shared Google Docs they update by hand.
- Paid tools they dislike — ****hey pay for a product that half-solves the problem and complain about it in the interview.
- Time on the clock — they can name how many hours a week the problem takes, without guessing.
- Delegation — they’ve hired someone, or asked a colleague, to deal with it for them.
2. The target segment is narrow enough to reach
“Small business owners” is a market. “Independent physiotherapists in the UK who still book appointments by phone” is a segment you can find and sell to.
Map out the first segment in detail and answer four questions before moving on:
- Where do these people spend time online, and which communities do they trust?
- Which apps do they already use daily, and on which devices?
- Who makes the purchase decision, and who only uses the product?
- What does it cost to put the offer in front of 1,000 of them?
Then we test reach with small paid campaigns or direct outreach in relevant groups. If we can’t get 200 people from the segment to a landing page at a reasonable cost, customer acquisition will cost a fortune after launch.
3. Demand exists before the product does
Interviews show what people say. Demand tests show what they do.
We set up a landing page that describes the product and its core benefit. Traffic comes from the channels we identified in step two.
Run fake door tests inside existing products or communities, where a button leads to a “coming soon” message and every click counts as a vote.
Not every signal carries the same weight. Here’s how we rank them, from weakest to strongest:
- Page visits and time on page
- Email sign-ups for a waitlist
- Demo bookings or survey completions with contact details
- Pre-orders, paid deposits, or signed letters of intent
The key rule is to set the success threshold before the test starts. When the team agrees that a 10% waitlist conversion means “go,” nobody gets to move the goalposts after seeing a 4% result.
4. Users reach the core value in the first session
Mobile users decide fast. If the app doesn’t show its value in the first few minutes, most of them won’t open it a second time.
As part of our digital product design services, we build a clickable prototype in Figma that covers the core flow, from the first screen to the moment the user gets what they came for.
Our team runs moderated tests with five to eight users from the segment and track:
- Time to value: how many seconds and taps it takes to reach the core moment.
- Hesitation points: screens where users pause, scroll back, or ask what to do.
- Wrong turns: taps on elements that aren’t interactive, which show where the interface misleads.
- First reaction: what users say in their own words when they reach the result.
When users need an explanation to get there, we redesign the flow before it reaches development.
5. Onboarding works without a guide
Onboarding is a tricky place that can either make it or break it.
We test onboarding with unmoderated sessions, where users complete the flow on their own while we record the screen. Track drop-off on every step, then test alternatives such as:
- Asking for notification access after the first completed action, when the benefit is obvious.
- Adding a short pre-permission screen that explains what the user gets in return.
- Letting users explore the app before creating an account.
- Removing fields that collect data the MVP doesn’t use yet.
Keep only what the first release actually depends on.
6. The riskiest technical assumption holds up
Most app ideas contain one technical question that could sink the whole project. Our engineers identify it during discovery. The usual suspects in mobile products include:
- Bluetooth or background sync with wearables and IoT devices
- Offline mode for users in the field, with conflict handling when they reconnect
- Real-time location tracking that drains the battery
- Third-party APIs with strict rate limits or unclear pricing
- KYC, payment, and open banking integrations in FinTech products
- On-device performance for camera, AR, or AI features
For the top risk, build a technical spike: a small, throwaway proof of concept that tests only that part. Check it on real devices, including the older phones many users still carry, and go over the vendor’s documentation, limits, and support terms.
When a spike fails, the team goes back to square one on paper, which costs days.
7. The platform choice matches the audience
iOS first, Android first, or both at once? The answer depends on the segment, the market, and the budget.
We start with platform data for the target market. In the US, iOS holds a large share of paying users. Across much of Europe, Asia, and Latin America, Android leads. B2B apps often depend on which devices a company issues to its staff. We confirm these numbers with survey questions and ad data from the demand test.
Then we compare build options against the product’s needs:
- Native: full access to platform features and the best performance, with two codebases to maintain.
- Cross-platform: one codebase for both stores and a smaller team, with some limits on deep hardware features.
- Single platform first: the fastest route to real usage data when the segment clearly favors one store.
We recommend the approach that fits the technical findings from step six, so the platform decision rests on facts rather than habit.
8. The monetization model works for real users
A product can solve a real problem and still fail on price. Each model shapes the product differently and carries its own risk.
Add a paywall screen to the clickable prototype and watch what users do when they hit it. Some pick a plan, some hunt for a free tier, and some close the app.
We run the numbers that founders sometimes discover late:
- Apple and Google take a 15% to 30% commission on digital purchases.
- Payment processors and tax handling add their own fees.
- Free trials delay revenue and need a clear conversion plan.
- Refunds and chargebacks hit subscription apps harder than one-time purchases.
The bottom line has to work after these deductions. Otherwise, the MVP proves demand for a product that can’t pay for itself.
9. Users come back after the first week
Downloads and first-session engagement are easy to get. Retention decides whether there’s a business behind the app.
To test retention before building, we use concierge and Wizard of Oz MVPs. Users interact with a simple prototype or even a messaging channel, while our team delivers the service by hand behind the scenes. For a meal planning app, that might mean a person creating weekly plans manually for 30 test users over four weeks.
During the test, we watch for:
- How many users return in week two, and how many are still active in week four
- Which actions come right before a return visit
- Which reminders bring people back, and which ones they ignore
- The point where users start asking for features on their own
This shows which features build a habit and which only shine in the first demo. It also tells us which notifications to design, because we’ve already seen which ones work.
10. Compliance and store review won’t block the launch
App Store and Google Play review can delay a launch by weeks when the product touches sensitive areas. On top of store policies, the product may fall under GDPR, HIPAA, PSD2, or local e-money regulations.
We check the concept against these rules during discovery. The areas that most often come up are:
- Health and biometric data storage
- Financial transactions, wallets, and lending features
- User-generated content and moderation
- Subscription terms, trial disclosures, and cancellation flows
- In-app account deletion, which both stores now require
For FinTech and HealthTech products, we bring in legal review early and plan the architecture around data storage, encryption, and consent. Some features move to a later release after this check, and that’s a good outcome. Building a feature the store will reject means throwing good money after bad.
How we turn validation results into a build plan
Ten tests produce a lot of data, and the value comes from what the team does with it. At the end of validation, we draw up a verdict for each test and choose one of three paths:
- Build. The core tests pass, so we lay out the MVP scope based on what users needed to reach value and come back. Unproven features go to the backlog, and development starts with the technical risks already resolved.
- Adjust. Some tests fail, so we change the concept and run those tests again. A different segment, a new pricing model, or a shorter core flow often turns a weak result into a strong one.
- Stop or pivot. The problem or demand tests fail outright. That conversation isn’t easy, but it saves founders months of development and a large share of their budget.
We’d rather deliver an honest answer early than build a product with no market.
Start with evidence
Validation takes a few weeks and a fraction of the development budget. In return, the team ships a smaller, sharper first release, launches with a clear picture of its users, and spends money on features people have already asked for.
Goodface leads mobile products from discovery to launch, covering product strategy, UX research, UI design, and native and cross-platform development. If you have an app idea and want to test it before committing to a full build, book a discovery call with our team. We’ll map out the riskiest assumptions in your concept and set up the tests to check them.
