Would you actually put money down right now to prove your app idea is worth designing? I mean really—would you risk your own cash on it? Because here's what I've learned after crafting digital experiences for over eight years: having a great idea isn't the same as having an idea people will pay for. Not even close. I've seen brilliant concepts that nobody wanted to spend money on, and I've seen fairly ordinary ideas that generated six figures in their first year. The difference? One group guessed, the other group tested.
Most people come to us with an app idea they're convinced will work. They've thought about it for months, maybe years. They've told their friends and family, who all said it sounds great (of course they did). They've done competitor research and found gaps in the market. All of that is useful, sure, but it doesn't answer the only question that actually matters: will people open their wallets and pay for this? Not "do they like it" or "would they use it if it was free"—will they pay?
The biggest waste in digital experience design isn't crafting the wrong features, its designing something nobody wants to pay for in the first place.
This guide is about proving payment intent before you spend a single pound on development. Not just validating that your idea is interesting or that people might download it—that's not enough anymore. We need to know if people will actually hand over money, how much they'll pay, and what kind of revenue model makes sense for your specific experience. I'm going to show you exactly how to test these things using real experiments that give you real data. No guesswork, no assumptions, just evidence you can base decisions on. Because honestly? Creating digital experiences is expensive and time-consuming, and doing it without knowing if anyone will pay is just a gamble you don't need to take.
Right, lets talk about the uncomfortable truth that nobody in the digital experience world really wants to discuss—most apps fail to generate any meaningful revenue. I'm talking about proper revenue here, not just a few quid from accidental in-app purchases. The numbers are honestly quite depressing; something like 90% of apps never see a return on their development investment.
But here's the thing—its not usually because the apps are badly designed or because they don't work properly. I've seen technically brilliant apps with beautiful interfaces that never make a single pound. The problem? Nobody actually wants to pay for what they're offering. Or worse, nobody wants the app at all. When you're selecting development partners, they should be asking you tough questions about market validation too.
The biggest mistake I see (and I see it constantly) is when someone creates an entire experience based on what they think people want, rather than what people have actually shown they'll pay for. You know what happens? They spend months perfecting features, refining the design, optimising interactions...and then launch to complete silence. Maybe their mum downloads it. Maybe a few mates give it a try. But real users who'll actually open their wallets? Nobody.
Sure, some apps get lucky—they go viral, get featured, catch a trend at exactly the right moment. But counting on luck is a terrible business strategy when you're investing thousands of pounds and months of work. What you need is validation before you design, not hope after you launch.
Right, so you've got an app idea and you think people might pay for it. But thinking and knowing are two very different things—and I've seen too many clients spend tens of thousands creating something nobody was willing to open their wallet for. The good news? You can figure out if people will actually pay before you design a single screen.
Here are the five methods I've used over the years to validate payment intent, from quickest to most thorough:
Create a simple webpage that explains your app and includes a "pre-order" or "get early access" button with a price attached. Drive some traffic to it through social media or small paid ads; if people click that button and enter their email (or better yet, their card details), you're onto something. I usually run these tests for about two weeks with a budget of £200-500. If you cant get at least 2-3% of visitors to show purchase intent, that's a warning sign. This early validation approach works particularly well when combined with building an email list before launch.
This ones a bit cheeky but incredibly effective. You create the appearance of a paid feature within a prototype or existing platform, and when someone tries to access it, you show them the price and ask if they'd like to purchase. They can't actually buy it yet—you're just measuring how many people would click "yes, buy now" versus "no thanks." Its brilliant for testing specific features or pricing tiers without designing anything real.
Whatever method you choose, always follow up with the people who showed interest. Ask them why they were willing to pay and what they expected to get. These conversations are gold—they'll tell you if you're solving a real problem or if they just liked your marketing copy.
The third method is the concierge approach. You manually deliver the service your app would provide and charge people for it. Yeah, it doesnt scale and its time-consuming, but it proves people will pay for the outcome. I worked with a fitness coaching app where the founder spent three months doing one-on-one video coaching sessions for £50 a pop before we designed anything; by the time development started, he had 40 paying customers and knew exactly what features mattered most.
Method four is the crowdfunding campaign. Platforms like Kickstarter or Indiegogo force people to put money down before you create anything—theres no better validation than that. But here's the thing: you need a compelling pitch and realistic goals. I've seen campaigns fail not because the idea was bad, but because the funding target was set too high or the rewards weren't appealing enough.
The fifth method is what I call the "competitor customer poaching" test. Find people already paying for a similar solution and offer them your app at a discount to switch. If they're willing to change providers and pay you money (even at a reduced rate), you know you're solving a real problem. This works particularly well in B2B scenarios where people are already budgeting for this type of solution. Before you can do this effectively, you'll need to identify your app's direct and indirect competitors properly.
Now, you don't need to do all five of these. Pick the ones that make sense for your specific app and target market. A B2B productivity app? Try the concierge method and competitor customer test. A consumer entertainment app? Landing page and fake door tests will give you quick answers without much investment.
The key thing is this: you're not trying to prove your app is perfect or that millions of people will pay for it. You're just trying to find evidence that a meaningful number of real humans will exchange their actual money for what you're offering. That's it. Anything else is just noise.
Right, so you've got an app idea and you need to find people who might actually pay for it—not just people who say "oh that sounds nice" and then vanish into thin air. This is where most app projects go wrong really quickly because finding the right people to test your idea with is honestly half the battle.
Here's the thing; you cant just ask your mates down the pub what they think. I mean, you can, but they'll probably tell you its brilliant even if it's rubbish because thats what friends do. You need to find people who have the actual problem your app solves and who are already trying to solve it in some way. These are the people whose opinions actually matter.
Start by looking at where people with your problem hang out online. And I don't mean everywhere on the internet—I mean specific places. Facebook groups work surprisingly well for this, especially niche ones where people actively discuss their problems. Reddit has communities for basically everything under the sun. LinkedIn groups can be gold if you're designing something for professionals. There's also forums, which still exist and are still useful despite what everyone thinks.
The trick is to lurk first. Spend time reading what people complain about, what solutions theyve already tried, and what they wish existed. You'll start to notice patterns in the language they use and the problems they face most often.
Once you've found where your potential customers are, you need to start conversations without being that annoying person who just spams their idea everywhere. I've found that offering value first works best—maybe answer someone's question or share something helpful before you ever mention what you're designing. Build a bit of trust, basically. Then when you do reach out to ask if they'd be willing to chat about their experience with whatever problem your app solves, they're much more likely to say yes. And you know what? Some people actually enjoy talking about their problems if they think someone might finally solve them. Later on, these same engaged users can become valuable beta testers who help market your app.
Right, so you've found some potential customers and now its time to actually test whether they'll pay for your app. This is where most people get nervous—because you're going to ask for money before you've designed anything. I get it, it feels a bit uncomfortable at first, but this is exactly what you need to do.
The simplest way to start? Create a landing page that explains what your app does and includes a price. You don't need anything fancy here; a basic page with a clear description, some benefits, and a button that says "Pre-order Now" or "Reserve Your Spot" will do the job. Tools like Unbounce or even a simple Carrd site work perfectly fine. What matters is that people can actually click through to a payment page.
Here's the thing—you need to be honest about what you're doing. When someone tries to pay, take them to a page that explains the app isn't ready yet but you're validating demand, and ask if they'd like to join a waiting list instead. Refund anyone who's already paid (this rarely happens with pre-orders anyway). Sure, you might lose a few people at this stage, but the ones who stuck around and provided their email? Those are your real potential customers.
The gap between saying you'll pay and actually pulling out your wallet is where most app ideas go to die, so test it early
Another approach that works well is running small paid ads to your landing page. I'm talking £50-100 maximum. Track how many people click through to the payment page versus how many just browse and leave. If you're getting clicks but nobody's attempting to purchase, that tells you something important about your pricing or your value proposition. Maybe both. You'll want to track your marketing performance carefully during these early tests to understand what's working.
For B2B apps, the validation looks a bit different; you'll want to set up meetings with decision makers and actually ask them to sign a letter of intent or put down a deposit for early access. If they won't commit even a small amount of money before you've designed anything, they definitely won't pay full price later.
Right, so you've run your experiments and collected some data—but here's where most people get it completely wrong. They look at the numbers and see what they want to see, not what's actually there. I've watched clients convince themselves that 5 email signups means they've validated a million-pound idea. It's a bit mad really.
Let me be clear about this; validation isn't about getting a few positive signals. Its about patterns. If you're testing with landing pages, you should be looking for conversion rates above 15% for early interest (that means 15 out of 100 visitors taking action). Anything below 5%? That's basically people clicking by accident or being polite. And don't get me started on asking your mates to sign up—their data is worthless for validation purposes.
When you run pricing tests, the real gold isn't in how many people say yes. It's in understanding who says yes and why they're different from the people who said no. What problems do they have that are more urgent? What's their budget like? Where did they come from? These patterns tell you exactly who your actual customer is, not who you hoped they'd be.
Here's what actually matters; if people are willing to put down a deposit or pre-order (even if its refundable), that's strong validation. Email addresses alone? Weak. Survey responses saying they "definitely would buy"? Nearly meaningless—people lie on surveys without even realising it. But when someone hands over their credit card details, even for a future purchase, that's real intent. The gap between "sounds interesting" and "here's my money" is enormous, and most app ideas never bridge it.
You should also be looking at the speed of response. If you have to chase people for feedback or it takes weeks to get traction, that's telling you something important about demand levels. Real pain points get quick responses because people are actively looking for solutions right now, not someday.
Right, so you've run your validation experiments and people seem interested in paying for your app. Brilliant news! Except—and here's where it gets tricky—there's a massive difference between someone saying they'll pay and someone actually paying. I've seen countless founders get burned by this, and honestly its one of the most painful lessons in app development because you don't realise the mistake until you've spent months (and thousands of pounds) creating something.
The biggest mistake? Asking friends and family what they think. I mean, of course your mum is going to say she'd pay for your app. She loves you! But that doesn't mean she represents your actual target market, and it definitely doesn't mean she'll hand over her credit card when the time comes. You need to test with people who have zero emotional connection to you—people who will be brutally honest because they've got nothing to lose.
Another common problem is making your validation test too easy to say yes to. If you're asking "would you pay £2.99 for this?" then people will often say yes because its a small amount and they want to be supportive. But if you actually ask them to commit right now—to pre-order or join a waiting list with payment details—that number drops dramatically. The friction of real commitment separates genuine interest from polite nodding.
Here are the most common ways founders trick themselves into thinking they've got validation when they haven't:
If someone won't give you their email address or commit to a waiting list, they definitely won't pay for your app. Real validation requires real commitment—even if its just a small one.
People are generally nice. They don't want to hurt your feelings. So when you show them your app idea and ask if they'd use it, they'll probably say yes even if they have no intention of actually doing so. This is especially true in certain cultures where direct rejection feels rude; I've run validation tests where the same concept got 80% positive responses in person but only 12% actual sign-ups online where people felt more comfortable being honest.
The solution? Make your validation test require something from them. Time, money, attention—something real. If they won't trade anything for access to your app, they won't pay for it later. It's that simple really, and yet so many founders skip this step because they're scared of hearing no.
Early adopters will try anything new and shiny. They'll pay for beta access, they'll tolerate bugs, they'll give you detailed feedback at 2am. But here's the thing—they represent maybe 2-3% of your potential market. Just because tech enthusiasts are excited about your productivity app doesn't mean busy parents or small business owners will care at all.
I've seen this play out dozens of times; an app gets great traction with early users, the founder raises money based on that validation, then growth completely stalls once they've exhausted the early adopter pool. The mainstream market has different needs, different pain points, and a much lower tolerance for complexity or rough edges. Your validation needs to include people who represent your actual long-term market, not just the people who'll try anything new.
Right, so you've run your experiments and people are actually willing to pay for your app idea—bloody hell, that's a good feeling isn't it? But here's where most people mess up: they either charge too little because they're scared of losing customers, or they pick a random number that "feels right" without any real justification. Neither approach works particularly well when you're trying to build a sustainable revenue framework.
The validation data you've collected is gold dust for pricing. Look at what people actually paid during your tests, not what they said they might pay. There's usually a big difference there, trust me. If you ran landing page tests with different price points, compare the conversion rates—sometimes a higher price actually converts better because it signals quality and seriousness. I've seen this happen more times than I can count.
Your pricing model needs to match how people want to use your app. Is it something they'll use daily or occasionally? That matters. Daily use often justifies subscription pricing, whilst occasional use might work better with one-off purchases or pay-per-use models. The data from your validation tests should tell you this—how frequently did your test users engage with the concept?
One thing people often forget: your initial pricing isn't permanent. Actually, changing prices later is quite normal in the app world. But starting too low makes it really hard to raise prices without annoying your early adopters. Starting high gives you room to run promotions and test lower price points without devaluing what you've crafted.
Use your validation data to set a price range rather than a single number. Maybe you found that 60% of people would pay £5 but only 20% would pay £10. That's useful information—you might start at £7.99 and see how the market responds when you launch properly. Once you've got your pricing sorted, you'll want to think about getting press coverage for your launch to maximise your initial impact.
Look, proving that people will pay for your app isn't some mysterious process that requires a business degree or years of experience—it just requires you to actually ask people and listen to what they do, not what they say. I mean, really listen. The difference between apps that generate revenue and those that don't usually comes down to whether the founder took the time to validate willingness to pay before spending tens of thousands on development.
You've got the methods now. Pre-orders, landing pages with pricing, concierge testing, competitor analysis, payment intent surveys—these aren't theoretical exercises. They're practical tools I've seen work time and time again across different industries and app types. But here's the thing—knowing about these methods and actually using them are two very different things. Most people will read this, nod along, and then skip straight to development because its more exciting than validation work. Don't be that person.
The data you collect during validation isn't just about proving people will pay (although that's bloody important). Its about understanding how much they'll pay, when they'll pay, what features they'll pay for, and which payment model makes the most sense for your specific audience. This information becomes the foundation for everything else—your development priorities, your marketing messages, your pricing tiers, your entire go-to-market strategy.
Remember that validation isn't a one-time thing either. Your apps revenue model should evolve as you learn more about your users and as the market changes around you. The apps that succeed long-term are the ones that keep testing, keep listening, and keep adapting their monetisation approach based on real user behaviour. Start small, test fast, and let actual payment data guide your decisions instead of assumptions. That's how you design an app experience that doesn't just get downloads—it generates real revenue. We craft the psychology-based design, user research, and experience strategy that becomes the blueprint any development team can then implement. Without this foundation, you're asking developers to guess what users need and what they'll pay for. Start with experiences designed by experts.