Validation and discovery
App idea validation and discovery company: find out before you fund the build
Most failed apps did not fail in development. They failed earlier, when nobody checked whether people wanted the thing, or the scope tried to do everything at once. As an app idea validation and discovery company, we help you test demand cheaply, then turn what you learn into a build plan: user flows, a prioritised backlog, a clickable prototype and a fixed price. This is one of our mobile app consulting engagements, and you own every deliverable whether or not we build the app.
- Validation tests chosen to fit your budget
- Discovery in one to two weeks
- Fixed price for the build afterwards
- NDA signed before you share the idea
Validation and discovery are two different jobs
Validation asks should this exist? It tests whether a real group of people has the problem, cares enough to change behaviour, and would pay or engage. Discovery asks what exactly do we build first? It turns a validated idea into flows, scope and a plan a team can estimate.
Skipping validation is the expensive mistake: a well-run build of something nobody wants. Skipping discovery is the slow one: a build that starts with a vague brief, then keeps changing as everyone learns what they meant. We run them in that order, and we are happy to stop after validation if the evidence says stop.
Some ideas need little validation. An internal app replacing a paper process, or a client app for an existing customer base, already has users and a known problem. In those cases we go straight to discovery.
App idea validation methods, from cheapest to most convincing
We pick the cheapest test that can answer your riskiest assumption. Many ideas need only two or three of these.
| Method | What it tests | What good evidence looks like | Watch out for |
|---|---|---|---|
| Problem interviews | Whether the problem is real, frequent and painful | People describe the problem unprompted and what they already do about it | Leading questions; friends being polite |
| Competitor and review research | Whether existing apps leave a gap | Repeated complaints in store reviews that your idea answers | Mistaking a crowded market for no demand |
| Landing page smoke test | Whether a clear promise attracts sign-ups | Visitors from a defined audience leave an email or join a waitlist | Testing with untargeted traffic |
| Fake door test | Interest in one specific feature or price | Clicks on a feature or plan that does not exist yet, followed by a short explanation | Annoying real users; be honest on the next screen |
| Clickable prototype tests | Whether people understand and can use the core flow | Testers finish the key task without help and ask when it launches | Testing only with people who already know the idea |
| Concierge or manual MVP | Whether people use and pay for the outcome | Repeat use of a manual service delivered by people, before any app | It does not test the app experience itself |
| Pre-orders or letters of intent | Willingness to pay | Money or signed intent from target customers | Small samples; B2B intent that never turns into a contract |
We help design and run the tests. Recruiting participants from your own network or customers is usually fastest; paid recruitment can be added if needed.
Start with the riskiest assumption
Every app idea rests on a handful of assumptions: that a group of people has a problem, that they will try a new app for it, that they will come back, and that someone will pay. One of these is usually much weaker than the rest. We write them all down in the first session and test the weakest first.
For a marketplace, the risky assumption is often supply: will enough providers join before customers arrive? For a consumer subscription, it is usually retention. For a B2B tool, it is whether the person who feels the pain controls the budget. Testing a different, safer assumption first feels productive and teaches you little.
We also set a stop rule before any test runs: what result would make you change direction? Writing it down in advance stops everyone from reading a weak result as a win. Our guide on how to validate an app idea walks through interviews, smoke tests and concierge MVPs, with kill criteria for each.
Questions we ask in the first session
- Who exactly has this problem, and how often?
- What do they do about it today?
- Why would they switch to an app?
- How will the app make money?
- What would make you stop?
Have an idea you want to test before you build?
Tell us the idea, who it is for and what you have learned so far. We sign an NDA first, then reply within one business day with the test we would run first.
Discovery workshop agenda
Discovery takes one to two weeks of workshops, timed for your time zone. This is the agenda for a typical two-week discovery; a smaller app compresses it into one week.
| Session | Focus | Who should attend |
|---|---|---|
| 1. Goals and constraints | Business goals, success metrics, budget range, deadlines, compliance needs | Founder or product owner, budget holder |
| 2. Users and problems | User types, their jobs, findings from validation, the core loop | Product owner, anyone who talks to customers |
| 3. User story mapping | End-to-end flows mapped as a story map, then sliced into releases | Product owner, our lead designer and developer |
| 4. Scope cut | What goes in the first release, what waits, what is dropped | Decision makers only |
| 5. Technical approach | Platforms, native vs cross-platform, backend, integrations, data and security | Your technical lead if you have one, our architect |
| 6. Prototype review | Walk through the clickable prototype, fix confusing steps | Product owner, a few target users if possible |
| 7. Plan and estimate | Backlog with acceptance criteria, release plan, risks, fixed price | Founder, budget holder |
Between sessions, our team drafts flows, wireframes and the backlog so each workshop reviews real material, not blank pages.
What you get at the end of discovery
These are working documents for building, not a slide deck. They belong to you and any competent team can use them.
- A one-page product summary: users, problem, core loop, success metrics
- User flows and a story map for the first release and the next one
- A prioritised backlog with acceptance criteria for every first-release story
- A clickable prototype in Figma for the core flows
- Technical approach: platforms, framework, backend, integrations and hosting
- A risk register with the open questions and how each will be resolved
- A release plan in two-week sprints
- A fixed price and timeline for the first release
- A list of accounts and assets you need to set up (developer accounts, domains, payment provider)
How discovery connects to the build
Discovery output flows straight into delivery. The backlog becomes the first sprints, the prototype becomes the design brief, and the fixed price is the build contract if you continue with us. MVPs typically take 8 to 16 weeks after discovery, as explained on our MVP app development page. For context, Clutch’s app cost research puts typical project length at about 11 months, which is why a tight first release matters.
If the idea still needs more evidence after discovery, a narrow proof of concept can test a risky technical piece, and a deeper prototype can come from our app prototyping and wireframing team. When the open questions are about architecture, scaling or vendor code rather than the product, see our technical architecture consulting.
Want to prepare before the first workshop? Our app requirements document template covers the information that makes discovery faster.
When an app idea validation and discovery company is not what you need
If you already have a detailed specification, tested designs and an engineering lead, a full discovery repeats work you have done. A short review of your documents and a direct estimate is enough. If the idea can be tested with a spreadsheet and a WhatsApp group, do that first and come back with the results.
We also say so when validation goes badly. If interviews show the problem is mild or the market is served well, the most useful thing we can do is tell you, before you spend on a build.
Worried about sharing the idea? We sign an NDA before discovery, and our guide on protecting your app idea when outsourcing covers the rest.
Discovery engagements
[[Add 1–2 anonymised validation or discovery examples: the assumption tested, the method, what was learned, and what the client decided next. Only with client permission.]]
[[Add a verified client quote.]] See also our portfolio.
App idea validation and discovery: frequently asked questions
How do I validate an app idea before building it?
Write down the assumptions the idea depends on and test the weakest first. Problem interviews, competitor review research, a landing page with a waitlist, a clickable prototype test and a manual concierge version are the common methods. Decide in advance what result would make you change direction, so a weak result is not read as success.
What happens in a discovery workshop?
Over one to two weeks, we agree goals and success metrics, map users and flows, cut the first-release scope, choose the technical approach, review a clickable prototype and finish with a prioritised backlog and fixed price. Between sessions our team drafts the material, so each workshop reviews real work rather than starting from blank pages.
How long does app discovery take?
One to two weeks for most apps. A focused MVP with one user type fits in a week. Marketplaces, regulated products and apps with several integrations need the full two weeks. Validation tests before discovery vary more, from a few days of interviews to a few weeks for a landing page test with paid traffic.
Do I have to build the app with you after discovery?
No. Discovery is a separate, fixed-scope engagement and you own all the deliverables: backlog, prototype, technical approach and estimate. Any competent team can use them. Many clients continue with us because the fixed price is ready, but that is your choice.
Will you tell me if my app idea is not worth building?
Yes. If the evidence from interviews or tests says the problem is weak, the market is well served or nobody will pay, we say so plainly and suggest what to change or test next. Being told early is far cheaper than finding out after months of development.
What should I prepare before discovery?
Anything you already know: who the users are, notes from customer conversations, competitor apps you admire or dislike, your budget range and deadline, and any compliance needs. Rough sketches help. You do not need a specification; producing one is the point of discovery.
Test the idea, then plan the build
Book a 30-minute call. Tell us the idea and what you know so far, and we will suggest the first validation test and a fixed discovery scope.