Most apps that fail do so before they're even built—not because of bad code or poor design, but because someone skipped the discovery phase entirely. They jumped straight into development without really understanding what they were building or why. I've seen it happen more times than I care to count, and its always painful to watch because these failures are completely avoidable.
The discovery phase is basically the planning stage that happens before any actual development work begins. It's where we figure out what needs to be built, who its for, and how we're going to make it happen. Think of it as doing your homework before the big test—you wouldn't walk into an exam without studying, right? Same principle applies here. During this phase we're mapping out the entire project, understanding the business goals, researching users, and making sure everyone involved knows exactly what success looks like.
The discovery phase isn't about building the app; its about designing the right experience.
Now I'll be honest, some clients get a bit frustrated with discovery work because it feels like you're not making progress—theres no shiny prototype to show off, no code being written. But here's the thing: every hour spent in discovery saves you at least three hours (and probably a lot more money) during development. I've worked on projects where we uncovered deal-breaking technical limitations during discovery that would have cost tens of thousands to fix later. We've also discovered that what the client thought users wanted was completely different from what they actually needed.
In this guide, we're going to walk through exactly what happens during the app discovery phase so you know what to expect and why each step matters for your projects success.
Right, so you've probably heard the term "discovery phase" thrown around a lot in the digital experience world—but what does it actually mean? I mean, is it just a fancy term agencies use to justify extra billing? Well, no. It's actually the most important part of the entire project, and skipping it is basically like building a house without checking if the ground is solid first.
The discovery phase is where we figure out what your digital experience needs to be, who its for, and whether it can actually work in the real world. Its not about designing screens or writing code yet; thats jumping ahead. This phase is all about asking questions, lots of them, and making sure we understand the problem before we start crafting the solution. You know what? Most app failures happen because teams skip this bit and just start building what they think users want—rather than what users actually need.
Here's what we're really doing during discovery:
Think of discovery as your insurance policy against designing the wrong thing. Sure, it adds time upfront—usually 2-4 weeks depending on complexity—but it saves months of wasted development later. I've seen projects that skipped discovery properly and ended up rebuilding their entire experience six months in because they realised they'd solved the wrong problem. That's an expensive lesson nobody wants to learn.
Right, so you've kicked off the discovery phase and now its time to actually talk to people. I mean, this is where things get interesting—and sometimes a bit uncomfortable if I'm honest. Stakeholder interviews are basically sitting down with everyone who has a say in your digital experience (the CEO, the marketing director, the head of IT, maybe even that person from finance who always has opinions) and figuring out what they actually want from this project.
Here's the thing though—everyone will have different priorities. The CEO wants the experience to drive revenue, marketing wants it to boost brand awareness, IT wants it to integrate with existing systems without causing them headaches. Your job during this phase is to listen to all these voices and find the common thread that ties everything together. Its not about making everyone happy with every feature; its about understanding the core business objectives that will actually move the needle for the company.
I always start these interviews with simple questions but they reveal so much: What problem are we solving? Who benefits from solving it? How will we measure success? What happens if we don't create this experience? You'd be surprised how often people haven't really thought through these basics before committing to digital experience design. And honestly, if you cant answer these questions clearly, you're not ready to start crafting anything yet.
During your stakeholder sessions, you need to dig out specific information that will shape your entire project scope. Don't just nod along—challenge assumptions, ask for examples, get them to explain why something matters to their department or to the business as a whole.
Once you've gathered all this intel, the next step is mapping business goals to actual experience features—and this is where requirements gathering really starts to take shape. You might have twenty different goals from various stakeholders but only five that really matter for your MVP. The trick is connecting what people say they want with what will actually drive value for users and the business. Sometimes what stakeholders think they need isn't what will solve their actual problem, and part of your role during the discovery phase is helping them see that distinction.
Record your stakeholder interviews (with permission obviously) because people often contradict themselves or remember things differently later. Having that recording to refer back to has saved me from so many "but I never said that" conversations down the line.
After you've done all your interviews, you need to synthesise everything into a clear business goal map. This document becomes your north star for the entire project—it shows how each proposed feature connects to a specific business objective and helps you make decisions when competing priorities emerge. And trust me, they will emerge! I usually create a simple matrix that shows business goals on one axis and proposed features on the other, then score how well each feature supports each goal. Its not perfect but it gives you a framework for those difficult conversations about what makes it into the experience and what doesn't. This kind of experience planning stops you from designing features just because someone senior thinks they'd be "nice to have" without any clear purpose behind them.
Right, so you've mapped out your business goals—now it's time to figure out who's actually going to use this experience. And I mean really figure it out, not just guess based on what you think people want. I've seen too many digital experiences fail because someone assumed they knew their users without doing proper research. Its painful to watch, honestly.
User research is about understanding the real people who'll have your experience on their devices. What are their habits? What frustrates them? When do they use similar experiences and why? You need to dig into their daily routines, their pain points, the experiences they already love (and the ones they've abandoned). This isn't fluffy marketing stuff—this directly affects every decision you make about features, design, and how the experience actually works.
We create detailed user personas during discovery, and these aren't just made-up characters. They're based on real data from interviews, surveys, and looking at how people currently solve the problem your experience addresses. A good persona includes age ranges, technical comfort levels, what devices they use, and crucially—what motivates them to try a new solution in the first place. Because let's be honest, peoples devices are already packed with experiences; you need a compelling reason for them to give yours a chance.
Here's what we're trying to learn during this phase:
I always tell clients that skipping this research is like building a house without knowing who's going to live in it. Sure, you might get lucky—but more likely you'll create something that doesn't fit anyone's needs properly. The experiences that succeed are the ones crafted with a crystal clear understanding of their target audience from day one.
Right, so you've got your experience idea and you've spoken to your users—brilliant. But here's the thing: you're probably not the only one who's had this idea. Actually, that's a good sign! It means there's a real market for what you're creating. The trick is figuring out how to position yourself differently from everyone else who's already out there.
When we do competitive analysis during the discovery phase, we're not just making a list of similar solutions and calling it a day. We're digging into what they do well, where they fall short, and more importantly—where the gaps are that your experience can fill. I always tell clients to actually use their competitors solutions for a few days; you need to feel the pain points yourself because that's where opportunities hide.
Look at things like their onboarding flow, their core features, how they monetise, what users are saying in reviews. The reviews are gold, honestly. People will tell you exactly what's missing or what frustrates them, and that becomes your roadmap for differentiation. Its not about copying what works and fixing what doesn't—its about finding your unique angle.
Understanding your competition isn't about creating a better version of what already exists; it's about identifying what the market needs that nobody's providing yet.
Market positioning comes next. This is where you decide who you're for and what you stand for in the crowded digital marketplace. Are you the premium option? The budget-friendly alternative? The one built specifically for a niche nobody else is serving? You can't be everything to everyone—and experiences that try usually end up being nothing to anyone. During this part of the discovery phase we help you define your positioning statement, your key differentiators, and how you'll communicate your value in a way that cuts through all the noise. Because there's a lot of noise out there.
Right, so you've got your business goals sorted and you know who your users are—now comes the bit where we figure out if this thing can actually be built. And I mean really built, not just theorised about. Technical feasibility isn't the sexiest part of experience design (its definitely not what gets clients excited) but skip it and you'll pay for it later. Trust me.
The platform question is usually the first one that needs answering. Do you create for iOS, Android, or both? And here's the thing—there's no universal right answer. Sure, native experiences for each platform give you the best performance and access to all the latest features, but it also means youre essentially creating two experiences. That costs more money and takes more time. Cross-platform frameworks like React Native or Flutter let you build once and deploy to both platforms; the trade-off is you sometimes cant access certain device-specific features or you might sacrifice a bit of performance.
What I typically recommend depends on your users. If your research shows they're mainly on iOS, start there. If budget is tight and you need both platforms quickly, cross-platform makes sense. But don't just guess—look at your actual user data.
During this phase, we dig into the technical requirements that'll make or break your experience. This includes things like backend infrastructure (do you need real-time data syncing?), third-party integrations (payment gateways, social media logins), and any hardware features you'll need access to like cameras or GPS. We also look at security requirements—especially important if youre handling sensitive user data or payments.
The goal here is to identify any technical roadblocks before they become expensive problems. Sometimes we discover that a feature a client wants is technically possible but would require so much development time that it doesnt make sense for an MVP. That's valuable information—it helps us make smarter decisions about what to design first.
Right, this is where things get real—and honestly, this is where I've seen more projects go wrong than anywhere else in the discovery phase. Its not because people don't know what features they want; its because they want ALL of them, right from day one. But here's the thing—trying to design everything at once is expensive, time-consuming, and usually leads to an experience that doesn't do anything particularly well. Your MVP (that's Minimum Viable Product, for anyone not familiar with the term) should be the leanest version of your experience that still solves the core problem for your users. Nothing more, nothing less.
I use a simple scoring system with my clients to work out what makes the cut for the MVP and what gets pushed to future releases. We rate each feature on two scales: how important it is to users, and how difficult it is to implement. The features that score high on importance but low on difficulty? Those are your quick wins—they go in the MVP first. Features that are important but complex need careful consideration; sometimes they're non-negotiable, sometimes we can find simpler ways to deliver the same value. And those features that are difficult to implement and not particularly important to users? They go on the "maybe later" list, or more often than not, they get binned entirely.
Actually, the method I just described is loosely based on something called MoSCoW prioritisation. It splits your features into four groups:
The tricky bit is being honest about what's truly a "must have" versus what's just something you really want. I mean, I get it—you've probably been thinking about this experience for months or even years, and every feature feels important to you. But users don't care about your vision for version 3.0; they care about whether version 1.0 solves their problem today.
Your MVP needs to do one thing brilliantly rather than ten things adequately. Sure, you might have plans for social sharing, advanced analytics, AI recommendations and a marketplace down the line. But if your core value proposition is helping people track their daily water intake, then your MVP needs a simple way to log water consumption and maybe send reminders. That's it. Everything else can wait until you've validated that people actually want what you're creating.
A good test for whether something belongs in your MVP: if you removed it, would users still be able to experience your core value? If the answer is yes, it probably doesn't need to be in version one. You can always add features later based on real user feedback rather than assumptions.
During this part of the discovery phase, we'll typically end up with a prioritised feature list that clearly defines what's in scope for the initial launch and what's planned for future releases. This becomes your roadmap—not just for development, but for budget planning and timeline estimation too. Because once we know exactly what we're crafting, we can give you realistic figures for what its going to cost and how long it'll take.
Right, so we've done all the research and know what features we're designing—now its time to actually show what this thing looks like. But here's the thing; wireframes aren't about making your experience pretty. Not yet anyway. They're about figuring out how everything works before we spend months implementing it. I mean, you wouldn't build a house without blueprints would you?
Wireframes are basically simple sketches that show where buttons go, what appears on each screen, and how users move through the experience. No colours. No fancy graphics. Just boxes and lines that represent the layout. And honestly? This is one of the most important steps because it's dead easy to change a wireframe—moving a button takes 30 seconds. Moving that same button after its been coded? That's expensive.
User flows are slightly different but equally important; they map out every possible path a user might take through your experience. What happens when they tap this button? Where do they go after completing that action? What if they get an error message? Sure, it sounds simple, but you'd be surprised how many edge cases pop up when you actually map this stuff out.
I've seen wireframes that are so detailed they might as well be the final design, and I've seen ones that are literally stick figures on napkins. Both can work, but there's a sweet spot. Your wireframes need enough detail that everyone understands what's happening, but not so much that you're wasting time on elements that'll change anyway.
The real value of this phase? It forces everyone—developers, designers, stakeholders—to agree on what we're actually crafting. When I skip this step (and yes, sometimes clients push to move faster), we always end up with confusion later on. Always. You know what's funny? The clients who initially resist spending time on wireframes are usually the ones who appreciate them most once they see how many problems we catch early.
Right, so you've done all this amazing work mapping out your experience—you know what it needs to do, who its for, and how it should work. Now comes the bit that makes everyone a bit nervous: working out what it's actually going to cost and how long its going to take. This is where a lot of projects go wrong because people either underestimate wildly or they get quoted some massive number that seems to have been plucked from thin air.
Here's the thing—good budget planning isn't about guessing. Its about breaking your experience down into specific features and understanding how much time each one requires. When I'm working through this with clients, we take every feature from the prioritisation exercise and estimate the development time. A simple login screen? Maybe 8-12 hours when you factor in design, development, and testing. A complex payment integration? That could be 40-60 hours depending on what payment providers you're using and how many edge cases we need to handle.
Timelines work the same way; we add up all those hours, factor in things like project management, quality assurance testing, and the inevitable back-and-forth during reviews. Most clients are surprised to learn that actual coding only makes up about 50-60% of the total project time. The rest is planning, designing, testing, fixing bugs, and making sure everything works properly across different devices.
The most expensive experience is one that fails because you didn't budget enough time for proper testing and refinement
I always build in a contingency buffer too—usually around 15-20% of the total timeline. Not because I'm bad at estimating (well, hopefully not!) but because requirements change, new technical challenges emerge, or you might decide that a feature needs reworking based on early testing. That buffer is what keeps your project on track when reality doesn't quite match the plan.
So that's the discovery phase—messy, challenging, and honestly one of the most important investments you can make in your experience's future. I mean, I get it, spending money before you've even started designing feels uncomfortable, but here's what I've seen time and time again: the experiences that skip this phase are the ones that end up costing three times as much because they have to rebuild everything halfway through. Its just not worth the risk.
The discovery phase isn't about making your experience perfect; it's about making sure you're creating the right thing for the right people. You might go in thinking you know exactly what your users want, but then your research shows something completely different—and that's okay. Actually, that's the whole point. Better to find out now than after you've spent six months and £100,000 building something nobody wants to use.
What I always tell clients is this: think of discovery as your insurance policy against expensive mistakes. You're not just creating documents and wireframes, you're creating a shared understanding between everyone involved in your project. Your developers know what they're building. Your designers understand the user's needs. Your stakeholders agree on the priorities. And you have a realistic budget and timeline that everyone can work with.
Look, creating digital experiences is hard enough without adding unnecessary uncertainty to the mix. The discovery phase removes that uncertainty—or at least as much as possible. It wont guarantee success (nothing can do that) but it gives you the best possible foundation to build from. And in my experience, that foundation makes all the difference between experiences that succeed and experiences that... well, dont.
The psychology-based design, user research, and experience strategy we craft during the discovery phase becomes the blueprint that any development team can then build from. Whether you work with freelancers, agencies, in-house teams, or AI tools, they're only as good as the experience design and technical roadmap you give them. We create that foundation - the emotional psychology, user research, and detailed roadmap that turns insights into reality. Let's craft your experience foundation.