How can I test my app idea without spending much money?

Somewhere between the idea and the app store listing, a lot of money disappears. Sometimes it goes on features nobody asked for. Sometimes it goes on a product that turns out to solve a problem only the founder actually has. Around 42% of startups fail because there is no market for their product, according to Edition Group, and the painful part is that most of those founders could have found that out for very little money before they spent the big amount.

Before you spend on building, spend on proving the need, because most failures are avoidable at the research stage.

The question founders usually ask us is how to build the app. The question they should ask first is whether to build it at all, and if so, what version of it. Those two questions are cheap to answer. Skipping them is what makes everything expensive. Getting something out to market, testing it, and iterating based on what real users tell you is always cheaper and more effective than trying to build the perfect product from the start. But you do need to confirm there is a market before you build anything.

This article walks through how to do that without burning through your runway before you have a single user.

Check whether anyone actually wants it first

The first instinct most pre-launch founders have is to map the competition. They build colour-coded spreadsheets comparing features across every rival product, which feels productive and satisfying. What it does not do is tell them whether anyone actually wants the thing they are planning to build.

A spreadsheet full of competitor data gives you unchallenged validation of your own existing opinions. Nothing in it can contradict you. That is precisely why it feels so comfortable, and precisely why it is the wrong place to start. The people who matter are the users who would, or would not, pay for your product.

The fear underneath the spreadsheet habit is real. If you speak to potential users and they are not interested, the idea is in trouble. That is a frightening thing to find out. But finding it out at the research stage costs almost nothing. Finding it out after you have spent £40,000 on a build is a different conversation entirely.

The most basic validation check is a survey sent to the kind of people who would plausibly use your product. Forty or fifty responses, structured around the problem you think you are solving, will tell you quickly whether the need is widespread or niche. Social media groups, Reddit communities, and LinkedIn are all free to access and full of people willing to share opinions if you ask them clearly.

Before you design a single screen, write down the problem you believe your app solves. Then ask ten people outside your immediate circle whether they experience that problem. Their answers will tell you more than any competitor analysis.

Talk to real people, not a spreadsheet

Surveys give you breadth. Conversations give you depth. Both matter, and you need at least some of each before you commit to building anything.

A thirty-minute conversation with five or six people who fit your target user profile will surface things you would never think to put in a survey. How they currently solve the problem. What workarounds they use. What they have already tried and abandoned. What they would pay, and what they would not. These conversations cost nothing except time, and they consistently surface assumptions the founder did not know they were making.

The trap here is only speaking to people likely to agree with you. Friends, colleagues, and people who already know your idea are predisposed to be supportive. You need people who have no stake in your success, who will tell you the product sounds confusing or that they would never use it. That feedback is uncomfortable and also the most useful thing you will hear.

Jakob Nielsen's research, published by Nielsen Norman Group, found that testing with five users surfaces around 85% of usability problems. You do not need a large panel to get meaningful signal. Five honest conversations with the right people will reveal more than fifty polite ones with the wrong ones.

What a discovery phase actually tells you

Discovery is the formal version of what we have been describing. It is a structured process of research, conversations, and synthesis that happens before design and build, and its purpose is to make sure you are building the right thing rather than just building something.

We worked with a property developer building a concierge app for high-rise properties. They came to us with a pre-formed idea of what they wanted and a suggested budget, and they wanted us to validate their existing plan rather than question it. We persuaded them to run a proper discovery phase instead, including focus groups and user workshops with the residents who would actually use the product.

What the discovery revealed was that the product needed to be far simpler than they had envisaged. A long list of planned features dropped away entirely. The focus shifted from replacing the building's existing systems to creating a genuine human connection with residents. The result was a better product built for less money than the original plan would have cost.

Discovery does not slow you down, it stops you building the wrong thing at full speed.

That outcome is typical of what discovery produces. According to Nielsen Norman Group, investing more time in discovery reduces the risk of project failure by 75%. The process does not delay you. It stops you spending three months building something you will have to tear apart later.

A discovery phase does not need to take months or cost a fortune. Even two or three structured sessions with target users, followed by a clear synthesis of what you heard, will give you enough to make confident decisions about what to build first.

How to run a focus group or user workshop on a tight budget

A focus group sounds expensive. It does not need to be. Five to eight people, a clear set of questions, two hours, and a quiet room is all you need to run something genuinely useful.

Finding participants without a budget

Online communities in your product's sector are the fastest free route to participants. Facebook groups, subreddits, Discord servers, and LinkedIn all contain people who will join a video call if you explain what you are building and why their input matters. Offer a small thank-you, a £10 gift card or similar, and response rates improve considerably. You are looking for six to eight people who match your target user profile, and you rarely need more than two rounds of sessions to reach useful conclusions.

What to ask

The questions that produce the most useful answers focus on behaviour and experience rather than opinion. Ask people to describe how they currently handle the problem your app addresses. Ask them to walk you through the last time they encountered it. Ask what they tried that did not work. Opinion questions like "would you use this?" produce socially desirable answers. Behaviour questions produce honest ones.

Record the sessions with permission, then review them looking for patterns. Three people independently describing the same friction point is a finding. One person mentioning something unusual is worth noting but not worth building around. The discipline is in separating signal from noise, and that only comes from looking across the full set of conversations rather than reacting to individual responses.

The danger of building what you want instead of what users need

There is a version of product development that looks like user-centred design from the outside but is actually the founder's vision wearing a research costume. The founder runs focus groups and commissions surveys, but when the findings contradict their assumptions, they discount them. The data gets filed away and the original plan continues unchanged.

We have seen this play out in two projects we worked on, a fitness and wellness app and a grassroots football product. In both cases, the founders had strong personal conviction in their vision and had arrived at it because the product solved a problem they personally experienced. What they did not fully reckon with is that experiencing a problem yourself does not mean the broader market shares it. As Simon puts it, "it's very easy to think I have this problem therefore everyone has this problem, and that's just not the case."

In both projects, research produced findings that pointed toward a different product than the one the founder wanted to build. In both cases, the founders continued refining and perfecting rather than redirecting. The warning signs were visible early: an excessive drive to get the product perfect before launch, repeated requests to revisit decisions already signed off, and an unwillingness to ship anything until everything was exactly right. Both projects consumed their full budgets in design and build and never reached a fully live product.

A product shaped entirely by the founder's preferences rather than user evidence is what we call a vanity product. It is usually beautiful. It almost never finds its market.

What skipping a step actually costs you

The costs of skipping discovery or user research are not abstract. They show up as rework budgets, extended timelines, and features that have to be removed or rebuilt from scratch.

On a dating app project we worked on, focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component. They wanted to focus the research investment purely on onboarding, which was the part of the product they cared most about. We advised against it, but the call was theirs to make.

What we ended up building for the messaging section was generic, because without discovery there was no research base to build anything specific. The generic messaging feature allowed automated messages and fake messages, which directly contradicted the verified, bot-free premise the onboarding had been designed to deliver. The mismatch between the rigorously researched onboarding and the uninvestigated messaging system meant the entire messaging section had to be rewritten. That rewrite cost approximately £15,000 in additional budget and added two months to the project timeline.

The discovery work that was skipped would have cost a fraction of that. The pattern is consistent: the expense that seems avoidable at the planning stage tends to arrive anyway, later and larger, once the problem it would have surfaced has been built in.

If you are deciding which parts of your product to research and which to skip, prioritise the parts that are most novel or most tightly connected to your core promise. Generic features can sometimes be built from established patterns. Distinctive features cannot.

Build something scrappy to test the real thing

Once you have validated the need and shaped the idea through research, you still do not need to build the full product to test whether it works. A prototype, a clickable mock-up, or even a no-code version of the core flow will tell you things about user behaviour that no focus group can.

We worked with a client building a trading card platform who was struggling to get traction with investors using pitch decks alone. Slides describe a product. They do not let an investor feel whether the product makes sense or whether the interaction works. The client built a working version of the product using vibe coding tools, which are code-generation tools that let you get to a functional prototype without a traditional development team, and that changed the dynamic entirely. As Simon describes it, he "had a demonstrable product that he could show people and demo how the product was going to work, " and that put him in a much stronger position than any deck had managed.

What to test in a prototype

Focus prototype testing on the moments that matter most: can someone understand what the product does within the first sixty seconds, can they complete the first action without help, and does the core value of the product land before they hit any friction. These are the questions a prototype answers that a description cannot.

The scrappy version does not need to work perfectly. It needs to be real enough that a user's response to it reflects how they would respond to the actual product. A polished prototype that nobody can navigate is more useful than a perfect one that only the founder can operate.

The five things your idea must pass before you spend seriously

Before committing serious budget to design and build, we look for confirmation across five areas. A product that cannot clear all five is not ready to build at scale.

1. Validated user need, confirmed through focus groups or surveys with people outside the founder's immediate network, showing the problem is real and broadly shared.
2. A tested onboarding flow, run with real users to check that the first experience is comprehensible and low-friction without guidance from the founder.
3. A clear value proposition visible within the first sixty seconds of using the product, without the user needing to be told what it is.
4. The ability to complete the first value-generating action within the product without hitting friction, because a product that requires help to deliver its core promise has a structural problem.
5. No overwhelming of users early in the experience, which means resisting the urge to front-load every feature and letting the product earn the right to show more over time.

Secondary checks include whether the app store listing and screenshots clearly communicate the product to a stranger, and whether the framing of the product matches what users actually said they needed during research. A product that passes all five core checks and the secondary ones is genuinely ready for a proper build investment.

Conclusion

Testing an app idea cheaply is about spending in the right order. Research before design. Design before build. A scrappy prototype before a full product. Each step costs less than the one that follows it, and each one reduces the risk of the next one going wrong.

The founders who spend wisely are the ones who treat early research as an investment rather than a delay. They speak to real users. They run workshops. They build something small enough to learn from. And then, once they know the need is real and the product concept holds, they commit to building properly.

Consumer apps are long-term investments. The goal is to get something real to market, listen to what it tells you, and allocate your next round of budget based on evidence rather than assumption. That cycle, launch, learn, iterate, is how products find their market. Trying to build the perfect version before anyone has used it is how budgets disappear.

If you have an app idea and you want to know what to test, in what order, and how to interpret what you find, let's talk about your product.

Frequently Asked Questions