What Questions Should You Ask Before Any Code Gets Written?

The difference between a successful app project and one that goes off the rails usually comes down to the questions you ask before a single line of code gets written, and after working on app projects for the past ten years (some brilliant successes and a few painful failures), I can tell you that the discovery phase is where most projects are won or lost.

The most expensive mistakes in app development happen in the planning stage, not during coding

I've probably sat through 200 discovery meetings by now, and the pattern is always the same... clients who come prepared with clear answers to the hard questions end up with better apps, delivered faster and closer to budget. The ones who rush through discovery because they're eager to see something on a screen? They end up paying for it later, sometimes doubling their budget when we have to rebuild things that weren't properly thought through at the start. This isn't about being difficult or slowing things down, it's about making sure we're building the right thing for the right people, and that everyone understands what success looks like before we commit serious time and money to development.

Who Is This App Really For?

Every app project I've worked on has had a target audience, but the difference between a vague idea of users and a properly defined user base is massive when it comes to making design and development decisions. When someone tells me their app is "for everyone" or "for young professionals", I know we need to dig deeper because those descriptions are far too broad to be useful when making actual product decisions.

Proper research methods for app planning can help you identify exactly who your users are and what they need from your product.

The apps that perform best are the ones where we can describe the primary user in specific detail... not just their age and job title, but their daily habits, the problems they face, the other apps they use, and even the circumstances under which they'll be using our app. I worked with a healthcare client who initially said their app was for "patients with chronic conditions", but after proper discovery we narrowed it down to working adults aged 35-55 managing type 2 diabetes who struggle to remember medication times during busy workdays. That specificity changed everything about how we designed the notification system and the interface.

• What specific problem does this person face every day or week?
• When and where will they use your app (commuting, at home, at work)?
• What apps do they already use and love?
• What's their technical comfort level with smartphones?
• What would make them delete your app within the first week?

What Problem Are You Actually Solving?

This sounds like a simple question, but you'd be surprised how many app projects start without a clear, specific problem statement. I've seen businesses want to build an app because their competitor has one, or because they think they "should" have one, but when I ask what problem it solves that can't be solved another way... the room goes quiet. Apps are expensive to build and maintain, typically costing anywhere from £25k to £200k+ depending on complexity, so you need a really solid reason to justify that spend.

The best problem statements are specific and measurable. Instead of "customers find it hard to book appointments", I want to hear "customers call us during business hours but we miss 40% of calls because our team is busy, and we lose those potential bookings to competitors who answer faster". Now we're talking about something concrete that an app can fix, and we can measure whether it's working after launch. The problem should be painful enough that people will change their behaviour to solve it, because getting someone to download and use a new app requires them to break existing habits.

Write down the problem in one sentence without mentioning your app or any solution. If you can't do this clearly, you're not ready to start building yet.

I worked on an e-commerce app where the client initially said they wanted to "improve the shopping experience", which meant nothing useful for planning. After digging deeper, we found that their mobile website had a 78% cart abandonment rate because the checkout process required seven screens and constant zooming on small phone screens. That gave us a clear target and a way to measure if we'd succeeded.

How Will You Measure Success?

Before we write any code, I need to know what success looks like in numbers, not feelings. "We want users to love it" isn't a success metric, but "we want 40% of new users still opening the app weekly after three months" absolutely is. The metrics you choose will shape every decision we make during development, from which features to build first to how we structure the onboarding flow.

Different apps need different metrics based on their business model and goals. An e-commerce app might focus on conversion rate and average order value, while a content app might care more about time spent and return visits. A fintech app I worked on measured success by how many users completed their first transaction within 48 hours of signing up, because their data showed that users who made it past that milestone were ten times more likely to become long-term customers.

You need both short-term and long-term metrics. Short-term might be downloads and sign-ups, but long-term should focus on retention and actual usage. An app with 100,000 downloads but only 2,000 active monthly users has failed, regardless of what the vanity metrics suggest.

What's Your Budget and Timeline Really Look Like?

This is where many projects hit their first reality check, and I'd rather have this conversation early than six weeks into development when we're running out of money. The budget for building the app itself is just the start... you'll need ongoing maintenance (typically 15-20% of build cost annually), hosting and backend services (anywhere from £150 to several thousand a month depending on user numbers), app store fees (£79 annually for Apple, £20 one-time for Google), and a proper marketing budget because no one will find your app organically anymore.

Most app projects underestimate their true costs by 40-60% because they forget about post-launch expenses

For timeline, a genuinely simple app takes at least three months from start to launch (and I mean truly simple, like a basic content delivery app with no user accounts or complex features). A mid-complexity app with user accounts, payment processing, and backend integration typically takes five to eight months. For specialised sectors, like with mobile health app development, you need to factor in additional time for regulatory compliance and clinical requirements. Anything involving real-time features, complex data processing, or regulatory compliance can easily stretch to twelve months or more. I built a fintech app that took 14 months because we had to account for security audits, banking API integrations, and financial regulatory requirements.

The temptation is always to compress the timeline or cut the budget, but this usually backfires. Rushing development leads to bugs, poor user experience, and technical debt that costs more to fix later. I've inherited probably 15 projects that were built quickly and cheaply by offshore teams, and the cost to rebuild them properly was often more than doing it right the first time would have been.

Who Are Your Competitors and What Can You Learn From Them?

Every app has competitors, even if they're not direct... they're competing for the same user attention, the same problem space, or the same time in someone's day. When I start a project, I spend hours downloading and using competitor apps, reading their reviews, and understanding what users love and hate about them. This isn't about copying, it's about learning from their expensive mistakes and understanding the baseline expectations users will bring to your app. If you want to do this properly, here's how to study your competitors without copying them.

User reviews of competitor apps are gold mines of information. When 300 people complain about the same friction point, you know exactly what not to do. When people rave about a specific feature, you know what table stakes look like. I worked on a restaurant booking app where competitor research showed that users absolutely hated apps that made them create an account before seeing available tables, so we made sure our booking flow showed availability immediately and only asked for account creation at the very end.

Look at apps outside your direct competition too. If you're building a healthcare app, sure, study other healthcare apps, but also look at the apps your target users actually use daily (WhatsApp, Instagram, their banking app) because those set the expectations for what "good" feels like. Users won't forgive clunky navigation just because your app is in a different category.

What Happens After Launch?

Launch day is really just the start of the journey, not the finish line, and the apps that succeed long-term are the ones with a clear plan for what happens next. You'll need a system for collecting user feedback, monitoring app performance and crash reports, responding to app store reviews, releasing regular updates with improvements and bug fixes, and gradually building out new features based on how people actually use the app. If you haven't already started thinking about your audience, consider building an email list before your app launches to ensure you have engaged users ready to provide feedback.

Plan to release a small update every 4-6 weeks after launch. Regular updates signal to users and app stores that your app is actively maintained and improving.

Who will handle support questions when users get stuck or encounter problems? You'll get them, I promise. Who will respond to app store reviews (both positive and negative)? Who will monitor your backend systems and server costs as user numbers grow? Who will make decisions about which features to build next based on user requests and usage data? I've seen too many apps launch successfully and then slowly die because no one had time or budget allocated for ongoing maintenance and improvement.

Budget for at least six months of post-launch support and updates. This includes fixing bugs that only appear at scale, optimising performance as usage patterns become clear, and responding to user feedback. An app I worked on for an education client launched smoothly, but within two weeks we discovered that users in rural areas with slower internet struggled with our video content... something we hadn't caught in testing. Having budget and time allocated for post-launch meant we could quickly add video quality options and offline download features. For apps with heavy visual content, understanding how to make your app load pictures really quickly becomes crucial for user retention.

What Could Go Wrong and How Will You Handle It?

Every app project faces problems, the question is whether you've thought about them in advance or whether they'll catch you completely off guard. I like to run through the likely failure points before we start so we can plan around them or at least not be surprised when they happen. This isn't pessimism, it's just realistic planning based on having seen things go sideways many times before. Understanding the risks of building a branded mobile app can help you prepare for potential challenges that could affect your brand reputation.

Technical risks are often the most obvious... what happens if your payment processor goes down, what if your backend can't handle the user load you're hoping for, what if Apple or Google rejects your app during review for policy reasons? Business risks matter too though... what if users don't understand how to use your core feature, what if your main differentiating feature turns out to be something people don't actually care about, what if a big competitor launches something similar right before you do?

• App store rejection (happens to about 40% of first submissions)
• Backend server costs higher than expected due to user growth
• Key features taking longer to build than estimated
• Users not understanding how to use the app without guidance
• Third-party APIs or services changing or shutting down
• Platform changes (like when iOS updates break existing functionality)

The apps that survive these challenges are the ones where we've built in some flexibility. This might mean architecting the backend so we can switch providers if needed, building the app in phases so we can test with real users before committing to expensive features, or keeping a financial buffer for unexpected costs. I had a retail client whose app depended on a specific payment gateway that suddenly tripled its fees six months after launch... because we'd built the integration properly with abstraction layers, we could switch to a different provider in three weeks rather than rebuilding the entire payment system. For apps handling sensitive user data, you should also consider auditing mobile API security before app launch to prevent security-related setbacks.

What Features Do You Actually Need Right Now?

This might be the most important question of all, because the biggest mistake I see is trying to build too much in version one. Every feature you add increases development time, increases testing complexity, increases maintenance burden, and most importantly, increases the chance that you'll run out of budget before launching anything at all. I've seen at least a dozen projects that never launched because they tried to build everything at once.

The apps that succeed are usually the ones that do one thing really well, not ten things poorly

Start with the absolute minimum feature set that solves the core problem you identified earlier. What's the one thing that has to work perfectly for users to get value from your app? Everything else can come later, based on real user feedback rather than assumptions. I worked with a client who wanted to build a fitness app with workout tracking, meal planning, social features, coach messaging, and a marketplace for fitness equipment... we convinced them to launch with just workout tracking and simple progress charts, and it turned out that users loved those features but had zero interest in the meal planning functionality they'd originally thought was critical.

A good test is to ask whether removing a feature would make the app pointless. If you can remove it and the app still solves the core problem, then it's not needed in version one. Payment processing, user accounts, push notifications, social sharing, advanced analytics... these can all potentially wait unless they're directly part of solving the main problem. Build the foundation solid, launch, learn from real users, then expand. For apps that do require user verification for safety or trust reasons, like dating apps, you'll need to plan for proper user verification systems from the start.

Conclusion

The questions in this guide aren't just a checklist to tick off before starting development, they're the foundation that everything else gets built on. When you can answer each of these clearly and specifically, you're ready to start building something that has a real chance of success. When you're fuzzy on the answers or skipping past them to get to the "fun" part of seeing designs and code... that's when projects run into trouble that could have been avoided.

I've built apps that succeeded beyond what anyone expected, and I've worked on projects that struggled despite having great teams and solid funding. The difference almost always comes back to how well we answered these questions at the start. The technical part of building apps is actually the easy bit (and I say that as someone who's been doing it for a decade), getting clear on what you're building and why is the hard part, but it's where the real value gets created.

Take your time with discovery. Push back on stakeholders who want to rush through it. Write down your answers and make sure everyone on the team agrees with them. These answers will guide a thousand decisions throughout the development process, from database architecture to button colours, and having them clear from the start will save you months of time and tens of thousands of pounds.

If you're planning an app project and want to work through these questions with someone who's done this many times before, get in touch and we can talk through your specific situation.

Frequently Asked Questions