Why this roadmap?
Building an app rarely goes wrong in the coding phase. It goes wrong because decisions are forced before the input is ready. Wireframes before the problem is sharply defined. Sprint planning before the scope is prioritised. App store submission before anyone has decided who manages the account. Each of these problems is cheap to solve in the phase before, and expensive (or impossible) after it.
This step-by-step guide breaks the process into ten phases. It is not a rigid waterfall model but a checklist for clients. For each phase, it sets out the goal, what should be ready before you move on, and the pitfalls first-timers most often stumble over. It is intended for founders, product owners, marketing and innovation managers, and IT managers who are commissioning external development for the first time. For scope prioritisation, see our MoSCoW model explained; for our approach, see the process page.
Ten phases, each with a clear "done" criterion. Don't skip a phase to save time: a skipped phase always costs you later, in sprints lost further down the line.
Phase 1: Idea validation
Before a single line of code is written, the core question must be answered: is the problem this app solves genuinely a problem for real people, and are those people willing to change their behaviour to solve it? Idea validation isn't about "believing in" the idea. It's about gathering evidence.
Speak with at least eight to ten people from your target audience, outside your own network. Don't ask "do you think this is a good idea?" Everyone will say yes. Instead ask: "When did you last have this problem, and what did you do?" If they answer "never" or "I used a spreadsheet", you will learn more than from a market report. Then write a problem statement of no more than three sentences: who has the problem, how often it occurs, and what the current (flawed) solution is.
- A problem statement of no more than three sentences, written down, not just held "in your head".
- Eight to ten conversations with people from the target audience, with verbatim quotes noted.
- An estimate of how often the problem occurs (daily, weekly, monthly).
- A hypothesis about who would pay for it (or which department has the budget for it).
- A first draft of the value proposition in one sentence.
Validating an idea with your own team or investors. That isn't validation, it's seeking confirmation. Only speak with people who actually have the problem, and whom you don't already know.
Phase 2: Research
Validation tells you there is a problem. Research tells you what already exists, how it is being solved, and where the gap is. There are two kinds of research you should always do: a competitor analysis and a technical feasibility check.
For the competitor analysis, search the App Store and Google Play using the two or three core keywords of your idea. Download the top five, use them, and read the reviews. One-star reviews are worth their weight in gold, because they reveal exactly what your target audience is missing. Build a matrix: feature, competitors A to E, and your planned approach. Where do you match, where do you differ, and is that difference meaningful enough to make someone switch?
For technical feasibility, look at integrations (which backend systems, which external APIs), privacy and compliance requirements (GDPR, sector-specific rules for medical or financial data), and platform particularities (push notifications, background processes, offline operation, biometrics). Not to choose solutions yet, but to prevent surprises later.
- A competitor matrix with at least five apps and their key features.
- An insight into what the target audience is missing in existing apps, based on reviews.
- A list of integrations with external systems (CRM, ERP, payment provider, maps, identity).
- Compliance requirements identified (GDPR, sector-specific, App Store rules).
- An initial indication of platform requirements: offline yes/no, push yes/no, biometrics yes/no.
"We're unique, there's no competition." That's almost never true. If you can't find any competitors, you're looking too narrowly. Instead, look at how your target audience currently solves the problem, often in a spreadsheet, a WhatsApp group or a paper process. That is a competitor too.
Phase 3 — Strategy & Goals
Strategy is the bridge between "we understand the problem" and "we're going to build something". You define what success looks like, how we'll measure it, and what the app is not meant to do. That last point is just as important: an app that tries to do everything ends up doing nothing well.
Define three to five goals, each with a measurable indicator. Not "we want more engagement", but "60% of registered users are still active in week two". Not "we want to save time", but "halve the average turnaround time of the current process". Making goals concrete forces focus.
This is also where you choose your business model: free with advertising, a one-off payment, a subscription, in-app purchases or a B2B licence. Each model has different implications. A subscription model requires Apple/Google in-app billing and a solid account system, while a B2B licence calls for SSO and an admin panel. Make these decisions now, not halfway through the build.
- Three to five goals, each with a measurable indicator.
- Explicit "non-goals": what this app will deliberately not do.
- Business model choice, with a rationale.
- Primary and secondary target audiences described (persona level, not demographics).
- A shared definition of "MVP" — the minimum needed to achieve the goals.
Framing goals as "making a beautiful app". Beautiful isn't a goal; it's a baseline requirement. Goals are about what the app should change for the user and for your organisation.
Phase 4 — MoSCoW Scope
This is the most underestimated phase of the entire process. Everyone wants everything in version one, and everyone painfully learns that this isn't possible, ideally not in week twelve of the build. The MoSCoW method forces these choices upfront by sorting every desired feature into four categories: Must have, Should have, Could have, Won't have (for now).
Must have is the make-or-break list: without these features the app isn't usable for its core use case. Keep this ruthlessly limited, often six to twelve items for a first version. Should have is important but can wait: if the build overruns, these are the first to go. Could have is nice-to-have if there's time left over. Won't have is a deliberate decision not to do something now, with the understanding that it can be discussed in a later version.
The trick of MoSCoW lies in that last list. "Won't have" stops the same feature being reopened for debate every two weeks. The decision has already been made, and it's recorded in black and white.
If your Must-have list is longer than twelve items, you're not building an MVP, you're building version 1.0 of what is really three products. Split it up.
- MoSCoW list completed and signed off by all stakeholders.
- Must-have list between six and twelve items.
- Won't-have list stated explicitly, so repeated discussions are avoided.
- For each Must-have: a one-sentence user story ("As a [type of user], I want [action] so that [value]").
- Acceptance criteria per Must-have: how we'll know the feature is done.
Lack of MVP discipline. "Everything has to be in there, otherwise the user won't understand it." This is almost always wrong. A user understands an app with one clear purpose far better than an app with thirteen half-finished features. Trust the power of focus.
Phase 5 — Wireframes & UX
Wireframes are the floor plan: screens in low fidelity, without colour and typography, focusing only on structure, navigation and information hierarchy. You start with pen and paper or Figma in black and white. Then comes a clickable prototype that lets a user walk through the main happy paths.
That prototype is your cheapest user test. Show it to at least five target users, give them a task ("register and place a first order"), and watch where they get stuck without your help. If three of the five misinterpret the same thing, that is not coincidence — it is a design flaw. UX also covers the less visible things: error messages, empty states, loading states, onboarding. These are often overlooked, and they are frequently the root cause of poor App Store reviews. Wireframe these too.
- Wireframes for all Must-have screens, plus error states and empty states.
- Clickable prototype tested with at least five target users.
- Findings incorporated (or deliberately not, with reasoning).
- Navigation structure decided (tab bar, drawer, or stack).
- Onboarding flow worked out — from first launch to the first moment of value.
Designing too early. People want to see the visual design and skip the wireframes. The result is discussions about colour instead of structure, and design rounds that have to be redone because the architecture is wrong. Wireframes first, colour later.
Phase 6 — Visual design
Only once the wireframes are right does the visual layer go on top: colours, typography, iconography, micro-interactions. The input is your brand identity; the output is a design system and hi-fi screens for all Must-have flows.
Don't design for a single device. iOS and Android have subtly different conventions — a back button, a navigation style, a typographic scale — which you can respect without creating two separate designs. Design dark mode at least for the main screens; in 2026 it is a standard expectation. The acceptance test is not "do we like it?" but "does it perform against the goals?" A button representing the primary action must be visually dominant — however attractive the rest is, hierarchy comes first.
- Design system (colours, typography, buttons, forms, cards) documented.
- Hi-fi screens for all Must-have flows.
- Designs checked against both iOS and Android conventions.
- Accessibility check: contrast ratios, touch targets of at least 44pt, dynamic text sizing.
- Designs handed over in Figma with inspect rights for the developers.
Don't deliver designs as PDFs instead of Figma. A PDF hides dimensions, margins and interaction states, forcing developers to guess and leading to endless correction rounds. Always deliver Figma with inspect rights.
Phase 7 — Development (sprint-based)
The build phase works best in short iterations in which a defined set of features is delivered, tested and reviewed internally. Each sprint ends with a working build that you can install on your own phone via TestFlight (iOS) or an internal Play Store track (Android). You see the app grow and can steer it before much has been built in the wrong direction.
The sprint rhythm has three fixed moments: sprint planning (what we are going to do, with which acceptance criteria), sprint review (what is done, a demo of the working build), and retrospective (what went well, what could be better). You attend planning and review; the retrospective is optional. Part of the build is also what is not visible in the UI: back-end APIs, the database, authentication, monitoring, and the CI/CD pipeline that pushes builds to TestFlight at the press of a button. In sprint one, ask for a diagram of the architecture — not to build it with us, but to understand where the choices lie.
Our approach works with a sprint budget and continuous delivery. The process page describes what a sprint looks like with us — from planning through demo to adjustment.
- All Must-have tickets for this sprint have met their acceptance criteria.
- Working build installed on real test devices (not just the simulator).
- Demo held, feedback addressed or prioritised for the next sprint.
- Nothing left in "in progress" across sprint boundaries.
- API endpoint documentation kept up to date.
Skipping weekly demos "because there's nothing visible yet". If nothing can be demonstrated after a two-week sprint, that is the signal, not a reason to skip the demo. Without visible progress you lose grip on the schedule.
Phase 8 — Testing (functional, security, accessibility)
Testing is not a separate phase at the end; it is a layer that runs through every build sprint. Even so, there is a testing period just before a release in which you review everything together. Three types of testing, none to be skipped:
Functional testing
Does every feature work as described in the acceptance criteria? Don't just test the happy path; also test edge cases: empty input, very long input, special characters, slow or no network, offline to online, background to foreground. An experienced tester will spot in no time things the builder never would have seen.
Security testing
At minimum an OWASP Mobile Top 10 check: insecure data storage, weak authentication, insecure communication (no TLS pinning), code injection. For apps handling financial or medical data, an external penetration test in this phase is advisable: not right before release, but while there is still room to fix findings.
Accessibility testing
Test with VoiceOver (iOS), TalkBack (Android), large dynamic text and high-contrast mode. Accessibility is not a nice-to-have; it is legislation (the European Accessibility Act), and it affects a broader group of users than many people realise. Apps that are fully broken with VoiceOver are increasingly rejected during App Store review.
- Test cases written for all Must-have features, including edge cases.
- Test data set available (realistic users, orders, products, scenarios).
- Security checklist (OWASP Mobile) completed, findings resolved.
- Accessibility audit with VoiceOver/TalkBack completed, critical issues resolved.
- Crash reporting active (Sentry, Firebase Crashlytics) and tested.
- Analytics events implemented so you can see metrics after launch.
No test data. A tester who has to create a user by hand every time they want to try something tests less. Deliver a seed script or a test database with representative data; it is work that pays for itself fifty times over.
Phase 9 — App store publication
The technical build is done; now comes the obstacle course: Apple App Store Review and Google Play Console. Expect at least one rejection round from Apple. That is not failure; that is how it works.
For Apple, watch out for: objections to privacy policy texts, the "Sign in with Apple" requirement if you offer other social logins, the in-app purchase rules (digital content MUST go through Apple's IAP, not an external payment link), and the "minimum functionality" rule: an app that does no more than a website will be rejected. Read the App Store Review Guidelines before the first submission, not after. For Google Play it is usually more lenient, but watch out for: the Data Safety form (a detailed declaration of what the app collects and why), target API level requirements, and the signing key, which you lose once and never get back. Keep the keystore in multiple secure places.
- Developer accounts set up in the name of your organisation (not a person).
- App Store Connect and Google Play Console set up, roles assigned.
- Privacy policy and terms and conditions published at a fixed URL.
- App icons, screenshots, descriptions, keywords prepared (per language).
- Apple App Privacy and Google Data Safety forms completed and consistent with reality.
- Keystore backed up in at least two secure locations.
- First submission sent, rejection round handled.
Tying app store accounts to one person. That person leaves, the account is only reachable through them, and your app hangs at enterprise level on a private Apple ID. Always use an organisation account, with a dedicated mailbox.
Phase 10 — Management & iteration
The app is live. No party, no finish line — a beginning. An app that isn't maintained on an ongoing basis becomes unusable faster than owners expect: iOS and Android release major updates every year (new API requirements, new permission models, deprecated frameworks), and if you don't keep pace, your app will eventually be pulled from the stores.
Maintenance has three layers. Operational: monitoring crash rates, performance, server uptime, cloud resource costs, and security updates for dependencies. Feature iteration: building further based on analytics and user feedback — no more guesswork, you now have data. Keeping pace with the platform: yearly iOS/Android major versions, new screen sizes, new accessibility requirements. Working on an ongoing basis with a fixed monthly sprint budget suits most parties best — you can adjust, and you don't pay a fixed sum for a feature package that doesn't exist. What you do not want is a "done is done" contract with no maintenance component — that is how apps fall into disrepair.
Reserve ongoing capacity for maintenance, even when "nothing new is being developed". Without that rhythm, it is the first line item to be cut — and six months later, getting back in step with the platforms costs three times as much.
- A monitoring dashboard with crash rate, latency and cost trends.
- A roadmap for the next two to three quarters, prioritised.
- An SLA or working agreement with the developer on response times for incidents.
- Ownership of the codebase, accounts and keys formally documented.
- A fixed cadence (monthly or quarterly) for jointly reviewing metrics and the backlog.
No post-launch plan. "We'll see how it goes." Three months later, this looks like: minor bugs remain unresolved, the first OS update breaks something, the developer is already on another project, and you are left on your own. Plan the first six months of maintenance before release.
What you do as the client at each stage
Building an app is not a tender where you hand in a specification and later receive a product. Your role as the client is an active one, and that active role determines whether the project succeeds. Here is what that looks like at each phase:
| Phase | What you do |
|---|---|
| 1. Validation | Conduct the conversations with your target audience yourself. No one else knows your idea as well as you do. |
| 2. Research | Get a feel for the competition, preferably installing and using the top five yourself. |
| 3. Strategy | Set the goals, and dare to state the "non-goals" out loud. |
| 4. Scope | Make the calls in MoSCoW discussions. You are the tiebreaker. |
| 5. UX | Be present at the user tests, not just read the report. |
| 6. Design | Test designs against the brand and goals, not just personal taste. |
| 7. Build | Attend every sprint review and don't postpone decisions. |
| 8. Testing | Take part in testing yourself rather than leaving everything to the tester. |
| 9. Publication | Manage the developer accounts and store content. |
| 10. Maintenance | Evaluate metrics monthly and recalibrate priorities. |
Without an active client, every app project turns defensive: the developer makes safe choices to avoid friction — and safe choices are rarely the best ones. Involvement and clarity lift a project from sound to good.
Frequently Asked Questions
Can I skip stages to speed things up?
What we see in practice is that skipped stages come back later with interest — a skipped validation stage pays off in an app nobody opens, a skipped scope stage in a backlog that never empties. Speed doesn't come from skipping stages; it comes from keeping each stage sharp and short.
What does it actually cost to build an app?
That depends on scope, platform choice, integrations and business model. See the guide on app development costs for the levers that drive the price.
Do we need someone in-house?
At least one product owner or equivalent role. No technical background is required, but you need someone who can make decisions without going back to a larger group every time. Apps built without such a person get stuck in decision-making, not in engineering.
How do I know whether my idea will be an internal business app or a public product app?
The difference lies in distribution, management and user experience. Internal business apps have their own pitfalls; if you're considering that route, read the guide to internal business apps and ten pitfalls.
Does this also apply to no-code or low-code platforms?
The first five phases are identical: validation, research, strategy, scope and UX are platform-independent. From phase six the work changes in detail, but the step structure stays the same. Never skip validation or scope because you're "quickly putting something together"; the most expensive no-code apps are the ones built without MoSCoW.
Who can I approach for a second opinion?
Send an email to fabian.vandijk@appfront.nl with where you currently stand. An introductory call lasts half an hour, with no pressure to buy a quote, just a conversation about where things are getting stuck. For our approach to app development, the service page explains how we work together.