What Happens Between Saying Yes and Writing Code?

What actually needs to happen before your developers write the first line of code for your mobile app... and why does this phase often take longer than clients expect?

After ten years building apps for everyone from healthcare startups to established fintech companies, I can tell you that the pre-development phase is where most projects either set themselves up for success or create problems that haunt them for months (learned that the hard way on a few early projects, honestly). The time between signing a contract and developers opening their IDEs isn't wasted time, it's when we build the foundation that determines whether your app launches smoothly or becomes one of those nightmare projects that goes over budget and misses deadlines.

The decisions you make before writing code determine ninety percent of your project's success

Most clients don't realise how much work happens in this phase because there's nothing visible to show for it at first. No screens to click through. No features to test. Just a lot of thinking, planning, and making sure everyone understands what we're actually building and why... which turns out to be the most important work of all.

Getting Everyone on the Same Page

The first thing we do is bring together everyone who has a say in the project, and I mean everyone who'll influence decisions down the line. This includes the client's team (project leads, department heads, technical staff if they have them), our own team (project manager, lead developer, design lead), and sometimes external people like marketing agencies or third-party service providers whose systems we'll need to connect with.

The kickoff meeting sets the tone for everything that follows. We go through the business goals behind the app, not just what features people want but why they want them and what success looks like in measurable terms. Is success defined by download numbers, by reducing customer service calls, by driving sales, or by improving some internal process? These aren't small questions.

We also establish how we'll communicate throughout the project. Who needs to approve what, who's the final decision maker when opinions differ (and they will), how often we'll have check-ins, and what tools we'll use to share progress. I've worked on projects where unclear communication chains added weeks to the timeline because feedback went through too many people or the wrong people were making technical decisions. Getting team communication and project management workflows right from the start prevents these delays.

• Define who approves design decisions
• Agree on technical decision makers
• Set up communication channels and frequency
• Establish escalation paths for blockers
• Document assumptions everyone is making

Understanding What You're Really Building

This is where we dig into requirements properly, moving beyond the initial pitch or brief to understand what the app actually needs to do. I start by asking clients to describe their users in detail... not just demographics but behaviours, motivations, problems they're trying to solve, and the context in which they'll use this app (commuting, at home in the evening, during work hours, in a rush). Before you even get to this stage, it's worth considering whether you need a full mobile app or if a responsive website might meet your needs.

Then we work through the feature list. Every single feature gets questioned. What problem does it solve? How often will people use it? What happens if we don't include it in version one? This process usually cuts the initial feature list by thirty to forty percent, which isn't about reducing scope to save money but about focusing on what matters and delivering a better experience.

Write user stories in this format: "As a [type of user], I want to [action] so that I can [outcome]." This forces you to think about the why behind every feature and often reveals when features are solutions looking for problems.

We create a requirements document that details every feature, how it should work, what data it needs, what rules govern its behaviour, and how it connects to other features. This document becomes our shared reference point. When questions come up during development (and they always do), we can refer back to it rather than relying on someone's memory of a conversation three weeks ago.

1. List all proposed features and functions
2. Define must-have versus nice-to-have items
3. Document business rules and logic
4. Identify data requirements for each feature
5. Note dependencies between features

Mapping Out the User Journey

Once we know what features we're building, we map how users will move through the app from the moment they open it for the first time. This isn't about visual design yet, it's about flow and logic and making sure the path through the app makes sense for how people actually think and behave.

The onboarding sequence gets special attention because it's where you either hook users or lose them. Data from apps we've built shows that if someone doesn't complete onboarding and use at least one core feature in their first session, there's a sixty percent chance they'll never open the app again. That's money down the drain in acquisition costs. Understanding how user frustration develops and what insights it can provide helps us design better onboarding flows.

We create flow diagrams that show every screen, every decision point, every path a user might take through the app. What happens when they tap this button? Where do they go if they skip that step? What if they don't have the information we're asking for? These diagrams look messy at first (covered in arrows and notes and "what if" scenarios) but they help us spot problems before they're written into code.

We also map out error states and edge cases. What happens when the internet connection drops mid-action? What if the user's account gets locked? What if they try to do something they don't have permission for? These scenarios don't get enough attention in planning but they're where user frustration builds up in real-world usage.

Figuring Out the Technical Bits

Now we get into the technical decisions that will shape how the app is built. Should we build native apps for iOS and Android separately, or use a cross-platform framework? Do we need real-time data sync or is periodic updating fine? What third-party services do we need to integrate with and do their APIs actually support what we need them to do (always worth checking early). The right platform choice depends on your specific requirements, timeline, and budget constraints.

We evaluate different approaches based on the specific requirements. A fintech app handling sensitive transactions might need native development for better security controls and performance. An e-commerce app that's basically a mobile version of an existing website might be better served by React Native or Flutter to share code across platforms and get to market faster. For some projects, we also consider whether progressive web apps might be suitable, though browser support limitations need to be factored into the decision.

Choose your tech stack based on your app's needs and your team's skills, not what's popular right now

Database architecture gets planned out at this stage too. What data do we need to store locally on the device versus fetching from a server? How do we handle offline functionality? What's our data sync strategy when connection comes back? I worked on a healthcare app where getting this wrong meant patient records could get out of sync between the app and the hospital system, which obviously couldn't happen.

Platform Considerations

We look at the specific capabilities and limitations of iOS and Android. Apple's App Store has different review guidelines than Google Play (stricter in some ways, more lenient in others). iOS users tend to spend more per transaction but Android has larger global market share. Some features work differently on each platform and users expect different interaction patterns based on which phone they're used to. Different markets have varying preferences too, so adapting your mobile strategy for local versus global markets becomes important if you're targeting multiple regions.

Security Planning

Any app handling user data needs a security strategy from day one. How will we handle authentication? Where do we store sensitive data and how is it encrypted? How do we secure API communications? What happens if a device gets stolen? These aren't add-ons you bolt on later, they're foundational decisions that affect the entire architecture. Implementing proper API monitoring and security measures from the beginning prevents costly security breaches later.

Planning Your Budget and Timeline

With the technical approach defined, we can create a realistic timeline and budget. I break the project into development sprints (usually two weeks each) and estimate how long each feature will take to build, working from the requirements we documented earlier. This is part science, part experience-based guesswork if I'm being honest. Planning should also include performance monitoring costs which are essential for maintaining app quality after launch.

The timeline includes time for things clients often forget about. Testing takes time. Getting through app store review takes time (usually a week for Apple, a few days for Google, but it can be longer if they find issues). Fixing bugs that come up during testing takes time. Making changes based on client feedback takes time. A twelve-week build isn't twelve weeks until launch, it's twelve weeks until we enter the testing and refinement phase.

Budget planning accounts for the full project scope. Development hours are the big ticket item, usually between sixty and two hundred grand depending on complexity. But there's also design work, project management, testing, server costs, third-party service fees, app store developer accounts (£79 yearly for Apple, £20 one-time for Google), and a contingency buffer for unexpected complications that come up in every project.

Sorting Out Design Direction

Before designers start creating actual screens, we establish the design direction. This includes looking at competitor apps to see what works well and what doesn't, reviewing the client's existing brand guidelines if they have them, and discussing the overall feel the app should have (professional and trustworthy, friendly and approachable, sleek and modern, fun and playful).

We create mood boards that show reference designs, colour palettes, typography choices, and interface styles we're considering. This gives everyone a visual language to discuss design preferences before designers invest hours creating detailed mockups. It's much easier to course-correct at the mood board stage than after someone's spent a week designing screens in the wrong direction.

Collect screenshots of three to five apps you think have great design (they don't need to be in your industry) and share them with your designer explaining specifically what you like about each one. This gives much clearer direction than saying you want something "modern" or "clean".

• Review competitor apps for inspiration and gaps
• Establish colour palette and typography
• Define interface patterns and components
• Create mood boards for stakeholder alignment

We also start thinking about the component library... the buttons, forms, cards, navigation patterns that will be reused throughout the app. Defining these early creates consistency and speeds up both design and development because we're not reinventing the wheel for every screen.

Setting Up for Success

With planning complete, we set up the project infrastructure that developers and designers will use. This includes creating shared file repositories, setting up project management tools, establishing naming conventions for files and code, and creating templates for documenting work and reporting progress. Proper version control setup for mobile development teams is crucial for managing code changes and collaboration effectively.

We define our quality standards and testing criteria. What browsers and devices do we need to support? What's the minimum acceptable app performance (load times, animation frame rates, battery usage)? What accessibility standards are we building to? These criteria give us objective measures to know when something is finished versus just sort of working. We also need to ensure we meet app store binary requirements and submission standards to avoid rejection during the approval process.

Risk management gets documented too. What are the biggest risks to the project succeeding (technical unknowns, dependency on third-party services, tight deadlines, unclear requirements, key team members leaving)? For each risk we identify, we think through mitigation strategies and early warning signs that the risk is becoming a real problem.

1. Set up version control repositories
2. Create project management boards
3. Establish file naming conventions
4. Define quality and performance standards
5. Document project risks and mitigations
6. Set up feedback and approval workflows

Testing Strategy

We plan our testing approach before development starts. Who will test and when? What devices do we need to test on (you'd be surprised how differently the same app can behave on different Android phones)? How will we track and prioritise bugs? What's the process for regression testing when we fix something to make sure we didn't break something else?

Preparing the Development Environment

The final pre-development task is getting the technical environment ready for developers to work efficiently. We set up development, staging, and production environments so code can be tested thoroughly before it reaches real users. We configure the backend servers, databases, and any third-party services we'll be integrating with.

Access credentials get sorted out. Does our team have the logins we need for the client's existing systems? Have we been added to their app store accounts? Do we have API keys for third-party services? These administrative tasks aren't exciting but sorting them out now prevents frustrating delays when developers need them mid-sprint.

A well-configured development environment can save your team hours every week

We create the initial project scaffolding... the basic file structure, core libraries, and configuration files that give developers a starting point rather than a blank screen. This includes setting up automated testing frameworks, continuous integration pipelines, and deployment scripts that will make the development process smoother and less error-prone.

Documentation standards get established. How should developers comment their code? Where do we document API endpoints and data structures? How do we track decisions and changes? Good documentation feels like busywork when you're doing it but becomes incredibly valuable six months into a project when someone needs to understand why something was built a certain way. Don't forget to document essential legal requirements like terms of service that need to be built into the app from day one.

Conclusion

The work that happens between contract signing and code writing isn't glamorous, you can't show it to users or celebrate its completion with an app store launch, but it's what separates projects that deliver on time and on budget from ones that spiral into expensive rewrites and missed deadlines. Taking four to six weeks to plan properly can save you twelve weeks of building the wrong thing or building the right thing in the wrong way. This planning phase is also when you should start thinking about building an email list and preparing your pre-launch marketing strategy.

Every hour spent in planning saves three or four hours in development and bug fixing later (I've tracked this on dozens of projects). The requirements you document now prevent arguments about what was agreed six weeks ago. The user flows you map out now prevent confusing interfaces that need redesigning. The technical decisions you make now prevent architectural problems that require rebuilding entire sections of the app.

This phase tests patience because nothing looks finished and clients are keen to see something tangible. But rushing through planning to get to code faster is a false economy. The apps that succeed are the ones built on solid foundations, with clear requirements, thoughtful technical choices, and everyone aligned on what success looks like and how we'll measure it.

If you're planning an app project and want help working through these pre-development stages properly, get in touch with us and we can talk through your specific needs and how we'd approach planning your build.

Frequently Asked Questions