How Do You Test Your App Idea Without Building Anything?

Most people think they need to spend months and tens of thousands of pounds building an app before they can find out if anyone actually wants it. I've seen this happen more times than I care to remember—someone comes to me with a fully formed vision, they're convinced their idea is brilliant, and they want to jump straight into development. But here's what usually happens next: they spend £30,000 or more building something only to discover that nobody downloads it, or worse, people download it once and never open it again. Its absolutely heartbreaking to watch, and completely avoidable.

The thing is, you don't need a single line of code to test whether your app idea has legs. In my years building apps for everyone from healthcare startups to major retail brands, I've learned that the most successful projects are the ones that validate their concept before spending serious money. The companies that skip this step? They're the ones who end up back at square one, having burned through their budget with nothing to show for it except some expensive lessons about what doesn't work.

Testing an app idea is about proving that people will change their behaviour, not just that they like the concept when you describe it to them.

What I'm going to show you in this guide are the actual methods we use at Glance to test app ideas without building anything. These aren't theoretical approaches—they're the same techniques we've used with fintech clients who needed to validate compliance features, e-commerce brands testing new shopping experiences, and education apps figuring out if students would actually engage with their content. Some of these methods cost nothing but time; others might cost you a few hundred pounds. But all of them will save you from making a very expensive mistake.

Why Most Apps Fail Before They Even Launch

The hard truth? Most app failures happen months before anyone writes a single line of code. I've seen it dozens of times—someone comes to me with an app idea they're convinced will be the next big thing, and within ten minutes of asking basic questions its clear they haven't actually validated whether anyone needs what they're planning to build. They've spent months refining features in their head, designing flows on paper, maybe even trademarking a name. But they haven't tested the fundamental assumption that people will actually use it.

There's this pattern I see constantly where founders fall in love with their solution before they've properly understood the problem. I worked on a healthcare app once where the client wanted to build a complex symptom checker with AI diagnostics. Sounds impressive, right? But when we actually spoke to their target users—busy parents with young children—we discovered they didn't want diagnosis tools at all. They wanted quick answers about whether something needed urgent care or could wait until morning. Completely different problem. We ended up scrapping half the planned features before even starting development, which saved them probably £40,000 in wasted build time.

The Real Reasons Apps Fail Early

Here's what kills apps before launch, based on what I've seen across hundreds of projects:

• Building for a problem that doesn't actually exist or isn't painful enough for people to change their behaviour
• Assuming you understand your users without ever speaking to them properly
• Copying competitors without understanding why they made certain decisions (or whether those decisions were even right)
• Overcomplicating the initial version with features nobody asked for
• Ignoring the business model until after you've spent your budget on development
• Underestimating how hard it is to get people to download and keep using a new app

The apps that succeed are the ones that validate every assumption before committing serious money to development. And I mean really validate—not just asking your mates if they'd use it, but testing with strangers who have no reason to be polite about your idea. Its uncomfortable, sure, but it's a lot less uncomfortable than launching something nobody wants.

Talk to Real People First

The biggest mistake I see with new app projects? People building things in isolation, convinced they already know what users want. I've watched teams spend months developing features that users didn't need, wouldn't pay for, or frankly couldn't even understand. One fintech client came to us after spending nearly £80,000 on an app that got 200 downloads in its first month—turns out nobody actually wanted to manage their investments through a chatbot interface, even though it seemed clever in the boardroom.

Before you sketch a single screen or write any code, you need to have proper conversations with the people who might actually use your app. Not your mates. Not your family (they'll tell you its brilliant no matter what). Real people who match your target audience and have no reason to be nice to you. When I say conversations, I mean actual back-and-forth discussions, not just firing off a SurveyMonkey form and calling it research. Understanding which problems are genuinely worth solving is crucial at this stage—identifying which user problems deserve your attention can save you from building features nobody actually needs. You want to understand their current behaviour, their frustrations, and what they're already doing to solve the problem your app claims to fix.

What to Actually Ask

The questions you ask matter more than you'd think. Avoid hypotheticals like "would you use an app that..." because people are terrible at predicting their own behaviour. Instead, focus on what they do now; how they currently handle the situation, what tools they use, where the pain points are in their existing workflow. I learned this the hard way with an e-commerce project where 90% of interview subjects said they'd love a feature for comparing prices across shops—then our analytics showed almost nobody used it once we built it.

Ask about the last time they experienced the problem, not whether they'd use your solution. Past behaviour predicts future behaviour far better than hypothetical scenarios.

How Many People Should You Speak To?

Here's where people overthink things. You don't need hundreds of interviews to spot patterns. In my experience, you'll start seeing the same issues crop up after about 5-8 conversations with people from your target group. If you're targeting multiple user types (say, both patients and doctors for a healthcare app), you'll need that many for each segment. But honestly? Five honest conversations will teach you more than fifty tick-box surveys.

The format matters too. Video calls work fine, but in-person conversations are better if you can manage them—you pick up on body language, see their environment, watch how they interact with their current tools. For a delivery app we worked on, sitting in actual restaurants and watching how staff managed orders on their phones revealed workflow issues we never would've spotted in a formal interview setting. They kept switching between three different apps, scribbling notes on paper, and getting interrupted mid-task... that observation alone shaped our entire approach to notification design.

• Speak to 5-8 people minimum from each user group you're targeting
• Focus questions on current behaviour and past experiences, not hypothetical futures
• Record conversations (with permission) so you can review them later without missing details
• Look for patterns in frustrations and workarounds people have already created
• Pay attention to what people do, not just what they say they do

One thing that catches people out is confirmation bias. You'll want to hear that your idea is good, so you'll unconsciously steer conversations that way. Fight that urge. The whole point of talking to people early is to find out where you're wrong, not to validate what you already believe. Some of my most successful projects started with conversations that completely changed the original concept—a retail client wanted to build a complex loyalty programme app, but user conversations revealed people just wanted to know if items were in stock before visiting the shop. We built something much simpler and it performed brilliantly.

Take notes during these conversations, but also step back and look for the bigger picture afterwards. What problems kept coming up? What solutions are people already cobbling together? Where's the genuine frustration vs. the nice-to-have improvements? This groundwork makes everything else in your validation process more focused and relevant. You're not just testing an idea anymore; you're testing a solution to real problems that real people actually have.

Paper Sketches and Simple Wireframes

Before you spend a penny on development, you need to get your ideas out of your head and onto paper. I'm talking actual paper here, not fancy design tools—just a pen and some A4 sheets. Its one of those things that sounds too simple to be useful, but honestly? I've saved clients thousands of pounds by spotting major issues at this stage that would've been expensive nightmares later on.

When I worked on a healthcare booking app a while back, the client was convinced they needed seven different screens just for the appointment flow. We sat down with paper and sketched it out together, and within twenty minutes we'd cut it down to three screens that actually made sense. The user didnt need all that complexity—they just wanted to book a bloody appointment and get on with their day. Drawing it out made that obvious in a way that talking about it never would have.

What to Include in Your Sketches

You don't need to be an artist. Boxes and lines work perfectly fine. What matters is that you're thinking through the actual user journey, screen by screen. Where do people land first? What do they need to tap next? Can they get lost anywhere? I usually sketch out these key things:

• The main screens users will see (home, profile, core feature screens)
• Navigation elements like bottom bars or menus
• Where buttons and forms need to go
• How users move between different parts of the app
• Any pop-ups or alerts that might appear

Moving to Basic Wireframes

Once your paper sketches make sense, you can move them into basic wireframes. I use tools like Balsamiq or even just PowerPoint—seriously, PowerPoint works fine for this stage. The goal isnt to make things look pretty; it's to test whether your flow actually works. Share these with potential users and watch where they get confused. That confusion is gold because its telling you exactly what needs fixing before you've built anything real.

Building a Landing Page That Tests Demand

A landing page is one of the fastest ways to validate whether people actually want your app—and I mean really want it, not just say they like it when you ask. I've seen clients spend £50 building a simple page that saved them from wasting £30,000 on an app nobody would download. The trick is treating it as an experiment, not a marketing exercise.

Your landing page needs one job: get people to commit. That commitment could be an email signup, a waitlist registration, or even a fake "pre-order" button (just refund them immediately with an explanation, obviously). I worked with a fintech client who built a one-page site explaining their budgeting app concept, added a Mailchimp form, and drove traffic through £200 worth of Facebook ads. They got 47 signups in a week—that was enough proof that people cared about the problem they were solving. Understanding what users are willing to pay for your app can also help you structure your landing page tests more effectively.

The best landing pages don't just collect emails; they tell you which features people actually care about

Here's what actually works: write a headline that describes the problem, not your solution. Use real language your users would use, not startup buzzwords. Add 3-4 bullet points about what the app will do (focus on benefits not features), include some kind of visual even if its just a simple mockup, and have a clear call-to-action above the fold. Tools like Carrd or Webflow let you build these in an afternoon without touching code.

The magic happens when you drive targeted traffic to it. Sure, you can share it with friends and family, but their feedback is basically worthless—they'll sign up to be nice. Spend £100-200 on Google or Facebook ads targeting your actual audience. If you cant get 20-30 signups from a few hundred clicks, that's a warning sign. I've tested dozens of concepts this way; the ones that work get 5-8% conversion rates, the ones that dont struggle to hit 1%.

Running Small Experiments on Social Media

Social media campaigns are brilliant for testing app ideas because you can get real feedback from your target audience without spending months building anything. I mean, you're literally putting your concept in front of people who might actually use it and seeing how they react. The best part? You can do this for £50 to £200 depending on your audience size and test duration.

Here's what actually works—create a simple video or image that shows what your app would do, not how it looks. People get caught up making fancy mockups when what you really need is a 15-second video explaining the problem and your solution. I've run dozens of these tests for clients and the ones that perform best are usually shot on someone's phone with basic text overlays. One fintech client tested three different value propositions this way and discovered that "split bills instantly" got 4x more engagement than their original pitch about "simplified group payments." Same concept, different framing, completely different response.

The metrics you want to track are engagement rate (likes, comments, shares) and click-through rate if you add a link to your landing page. Anything above 2% engagement is decent, above 5% means you've struck a nerve. But dont just look at numbers—read the comments carefully because people will tell you exactly what they think. Sometimes the negative feedback is more valuable than the positive stuff because it shows you the objections you'll need to address later.

Facebook and Instagram ads work well for consumer apps whilst LinkedIn is better for business or productivity tools. TikTok can be surprisingly effective if your target audience is under 35, though the creative needs to be more entertainment-focused. Run your test for at least 5-7 days to get enough data; anything less and you're basically guessing. And here's something most people miss—test different audiences with the same creative to see who responds best. You might think your app is for busy parents but discover that students are actually more interested.

Competitor Research Done Properly

Most people download three or four competitor apps, click around for ten minutes, and call it research. That's not research—that's procrastination dressed up as productivity. When I worked on a fitness tracking app project, the client had screenshots of Strava and MyFitnessPal, but they couldn't tell me why users were leaving one-star reviews or what features people actually used daily. We had to start from scratch.

Here's what proper competitor research looks like; you need to live with those apps for at least a week. Use them every day. Go through their entire onboarding flow. Try to accomplish specific tasks. Read the last 200 reviews—not just the top ones—because that's where you'll find the real pain points. I mean, its boring work, but this is where you discover that people love an apps core feature but hate that it takes five taps to access it, or that the subscription pricing confuses everyone. Learning how to research competitors without copying their mistakes is essential for avoiding the same pitfalls that are frustrating their users.

Pay attention to their App Store Optimisation too. What keywords are they targeting? How are they positioning themselves in screenshots and descriptions? When I analysed competitors for a meal planning app, I noticed they all focused on "healthy recipes" but nobody was targeting "quick meals for busy parents"—that gap became our clients main positioning and it worked brilliantly.

You should also track their updates. What features are they adding? What problems are they solving? An e-commerce client avoided wasting six months on a feature we nearly built because competitor reviews showed users hated it. That kind of insight is gold.

What to Actually Track

• User reviews from the past three months (sort by recent, not helpful)
• Number of screens to complete key tasks
• Onboarding flow length and what information they collect
• Monetisation strategy and pricing tiers
• Update frequency and what changes they're making
• Social media presence and how they engage with users
• Which features are hidden behind paywalls

Create a simple spreadsheet comparing five direct competitors across ten key features. But dont just tick boxes—note how well each feature actually works and what users are saying about it in reviews. This becomes your roadmap for what to do better.

The biggest mistake? Trying to copy everything competitors do well. You cant out-feature an established app with millions in funding. Instead, find the gaps. Find what users are complaining about that nobody's fixing. That's your opportunity.

Creating a Clickable Prototype

Once you've done your sketches and wireframes, the next step is building something people can actually touch—well, tap. A clickable prototype. I've seen so many founders skip this step because they're eager to start proper development, and honestly? That's where things start to go wrong. A clickable prototype lets you test the core user journey without spending thousands on development, and its something I insist on with every project we take on.

The tools have gotten really good for this. Figma's my go-to these days because it allows proper interaction design and clients can share prototypes instantly with their teams or test users. But Framer, Protopie, or even InVision work fine. What matters is that your prototype simulates the actual flow someone would take through your app—from opening it to completing their main task. For an e-commerce project we built, we prototyped the entire checkout process and discovered users were abandoning at the shipping options screen because we'd crammed in too many choices. Fixed that before writing a single line of code.

What to Include in Your Prototype

You don't need every screen. Focus on the core user journey, the thing someone does most often in your app. For a healthcare booking app we worked on, that meant going from "find a doctor" to "book appointment" to "confirmation". That's it. We didn't prototype the settings screen or help section yet.

• The main navigation between key screens
• Primary buttons and what happens when you tap them
• Any forms or input fields users need to complete
• Success states and error messages
• The onboarding flow if your app needs one

Testing Your Prototype

Get it in front of real people. Not your mum, not your business partner—actual potential users who've never seen it before. Watch them use it without giving them instructions. You'll spot problems immediately. They'll tap things you didn't make tappable. They'll expect information that isnt there. They'll get confused by navigation that seemed obvious to you. I've watched test users struggle with prototypes for apps we thought were brilliantly designed, and every time it's been valuable. One fintech app we developed had users repeatedly trying to swipe between accounts, but we'd designed it with a dropdown menu. Changed the entire navigation based on five user tests with a prototype—would've been a nightmare to change after development. Remember that designing buttons that everyone can actually press becomes crucial when you're watching real users interact with your prototype.

Measuring What Actually Matters

Right, so you've done all this validation work and now you're probably wondering what success even looks like at this stage. I see this confusion all the time—people get caught up tracking the wrong things and it completely throws off their decision making. The metrics that matter during validation are totally different from what you'll track once your app is live, and mixing them up is a common mistake that wastes a lot of time and money.

When I'm running validation tests, I focus on three main things: engagement rate, intent signals, and qualitative feedback quality. Engagement rate tells me if people actually care enough to interact with whatever I've put in front of them—whether thats a landing page, a prototype, or a social media post. If your landing page is getting 1000 visitors but only 12 people are signing up for updates, that's a problem you need to understand before building anything. Intent signals are actions that show genuine interest—things like email signups, pre-orders, waitlist registrations, or even just people asking detailed questions about features. These matter way more than vanity metrics like page views or social media followers. Once you've validated your concept, you'll need to start thinking about how to demonstrate your app's revenue potential to stakeholders or investors.

The goal isn't to prove your idea is perfect; its to find out if its good enough to justify the next step

For a healthcare app we validated, we tracked how many people completed a 5-minute survey about their pain points versus how many just clicked through the first page. The completion rate was 68%, which told us people were genuinely invested in finding a solution. Compare that to a fintech project where only 9% of visitors bothered to watch a 90-second explainer video—that was a red flag we couldn't ignore. Look for patterns in the feedback too. If three people mention the same concern, thats not a coincidence; its something your app needs to address. During this phase, quality beats quantity every single time.

Conclusion

Look, I'm not going to pretend that testing your app idea without building anything is easy. It's not. It takes discipline to resist the urge to jump straight into development when you're excited about an idea—I've seen founders waste hundreds of thousands because they couldn't wait just a few more weeks to validate properly. But here's what I know after all these years: the apps that succeed are the ones that prove themselves before a single line of code gets written.

What I want you to take away from this is simple. Testing your idea doesn't mean creating something perfect or comprehensive; it means answering the most dangerous questions first. Will people actually use this? Are they willing to pay for it? Does it solve a problem they care about enough to change their behaviour? I've watched a fintech client save nearly £180,000 by discovering through a simple landing page test that their target market wasn't interested in their proposed feature set—they pivoted based on the feedback and built something people actually wanted instead.

The methods we've covered aren't theoretical. They're what I use with every single client, whether its a two-person startup or a company you'd recognise by name. Paper sketches catch design flaws that would cost thousands to fix later. Clickable prototypes reveal user confusion before it becomes a one-star review. Competitor research shows you where the gaps really are, not where you think they are. And measuring the right metrics? That's what separates founders who learn from ones who just guess and hope.

Start small, test quickly, and be honest about what the data tells you. Your future self (and your bank account) will thank you for it.