App development process: a guide for the founder paying the bill

The app development process is sold as a six-stage conveyor belt. Here is what actually happens at each stage, what your one job is, and where founders quietly lose control of the build they are paying for.

A founder we worked with had approved everything. She had signed off on the wireframes, nodded through the sprint demos, and forwarded the launch date to her lead investor. Three weeks before go-live, her developer mentioned, in passing, that the app could not send a password-reset email. It had never been in scope. Nobody had lied to her. She had simply approved six months of work without once knowing what she was supposed to be checking at each step.

The app development process is the sequence a software idea travels through to become a working product: discovery, design, build, test, launch, and maintenance. Every agency and dev shop describes it as a tidy set of stages, usually numbered, usually with an arrow pointing right. That picture is true and useless. It is true because those phases really do happen in that order. It is useless because it is drawn from the builder’s seat, and you are not in the builder’s seat. You are the person paying for it, and your job at each stage is different from theirs.

This is a guide to the same six phases from where you actually sit. For each one: what happens, the single thing that is yours to get right, and the specific sign that the phase is going wrong while everyone is still smiling.

The one rule that governs the whole app development process

Before the phases, the rule that makes sense of all of them:

Your leverage over an app build is highest before a single line of code is written, and it drops every week after. Spend your attention where it is worth the most: the two phases before the build, not the standups during it.

Most first-time founders do the opposite. They stay hands-off during discovery and design, when a sentence from them could redirect the whole project, and then get anxious and involved during the build, when the expensive decisions are already poured in concrete. By the time you are watching daily standups, you are managing the weather. The leverage moved on without you.

Phase 1: Discovery, deciding what not to build

Discovery is where the team turns your idea into a specific list of what version one will and will not do. Good teams run interviews, sketch flows, and pin down the handful of things the product must do to be worth shipping. Weak teams skip it and start drawing screens, which feels like progress and is actually just guessing with a nicer tool.

Your one job here is subtraction. The team can add features all day; only you can decide what the business does not need in the first version. Every feature you cut in discovery is money you do not spend and a bug you never have to fix. This is the phase where the product discovery work pays for itself many times over, because it is the cheapest place in the entire process to change your mind.

The red flag: the team wants to start building in week one and treats discovery as a formality. A shop that is eager to skip discovery is a shop that gets paid to build, not to think, and the difference will show up in your invoice three months from now as rework.

Phase 2: Design, the last cheap place to be wrong

Design turns the discovery decisions into something you can see and click: wireframes first (the skeleton), then higher-fidelity mockups and usually an interactive prototype. This is the last phase where changing your mind costs an afternoon instead of a week. Moving a button in a design file is free. Moving it after it is wired to live data and tested is not.

Your job is to click the prototype like a suspicious customer, not to admire it like a proud parent. Try to do the three things your real users will do most. If any of them takes more taps than it should, say so now. Understanding the difference between a wireframe and a mockup matters here, because founders often approve a gray skeleton thinking they have approved the finished look, then feel misled when the real thing arrives.

The red flag: you are shown static images and asked to imagine the flow. If you cannot actually tap through the core journey before the build starts, you are approving a story about the app, not the app.

Phase 3: Build, where your leverage is already spent

Now the engineers write the code. This is the longest and most expensive phase, and, counterintuitively, the one where you have the least to add. The decisions that matter were made in the two phases you may have rushed through. What you can still do here is protect the build from yourself.

Every time you introduce a new idea mid-build, you are not adding a feature, you are reopening the plan. The team has to re-sequence work, and the cost is rarely just the new thing; it is everything the new thing touches. This is the mechanism behind most blown timelines. If you want to understand why the number moved, read your software development estimation as a range that assumes you stop changing your mind, because that assumption is doing a lot of quiet work.

Your one job during the build is to keep a working version in front of you. Ask for a link you can open, not a screen recording someone edited. Software that only exists in a demo is software you cannot inspect. The red flag is a build phase where every update is a slide and never a link.

Phase 4: Test, the phase that gets cut first

Testing is where the team tries to break the app before your customers do: does it work on a cheap Android phone, does it survive a bad network, what happens when someone types an emoji into the name field. It is the phase most likely to be quietly compressed when the build runs late, because it is the last one standing between a slipping date and a launch.

You cannot read the test code, but you can ask for the result: a short report of what was tested, what broke, and what was fixed. You are not auditing the engineering. You are checking that testing happened as an activity with an output, not as a word someone said in a meeting. The password-reset email that nobody scoped is exactly the kind of thing a real test pass catches and a compressed one does not.

The red flag: “we tested as we went” offered as a substitute for a test phase. Testing as you go is good practice and a bad excuse. If there is no artifact showing what was checked, assume the coverage is whatever was convenient.

Phase 5: Launch, an engineering event before a marketing one

Launch is not the party. It is the boring, high-stakes work of putting the app in front of real users on real infrastructure: app-store review, production data, monitoring, and a plan for the first time something breaks at 2 a.m. The marketing launch can wait a week. The engineering launch has a hundred small doors that all need to be closed, and most of them are invisible to you.

Your job is to know who is holding the pager. Ask one question: when something breaks in the first 48 hours, who notices, and how fast can they fix it. If the answer is vague, you do not have a launch plan, you have a hope. Launch also has gatekeepers you do not control: Apple’s App Store review guidelines can reject a build for reasons that have nothing to do with whether it works, and a rejection days before your date is a launch problem you want to hear about in phase one, not phase five.

The red flag: the go-live plan is a date and nothing else. A date is not a plan. A plan names who does what when the thing you did not expect happens.

Phase 6: Maintenance, the phase everyone forgets to price

Software is not a building that stands once you cut the ribbon. Phones update, libraries break, users find edges you never imagined, and the app needs steady, unglamorous attention to keep working. Maintenance is not a phase after the process; it is the process not ending. Founders who treat launch as the finish line discover this the first time Apple changes something and their app stops opening.

Your job is to refuse the framing that maintenance is optional. Decide, before launch, who keeps the lights on and what that costs each month. The cheapest version of this conversation happens now. The most expensive version happens after your one developer has moved on and nobody left can safely change a line.

The red flag: a proposal that ends at launch with no line for what happens after. A build with no maintenance plan is a car sold with no way to buy fuel.

The Handoff Test: how to know a phase actually ended

Here is the single tool that ties the six phases together. At every boundary between phases, there is an artifact you should be able to hold in your hand:

• After discovery: a one-page scope you can read in five minutes and that lists what is out, not just what is in.
• After design: a clickable prototype of the core journey, not a folder of images.
• After the build: a link to a working version you can open yourself.
• After testing: a short report of what was checked and what broke.
• After launch: a runbook naming who responds when something fails.

The test is simple. If a phase ends and you cannot hold its artifact, the phase did not really end. It just moved its risk downstream, to the next phase and ultimately to you. Every disaster in an app build is some version of a phase that was declared finished without producing the thing that proves it was. The Handoff Test is how a non-technical founder audits a process they cannot read the code of: you do not check the work, you check that each phase left evidence behind.

You will notice this also tells you which shop to trust. A team that thinks in artifacts hands them to you without being asked. A team that thinks in invoices hands you a status update and hopes you feel reassured. The way you choose a development company should lean hard on this: ask what you will be able to hold at the end of each phase, and watch whether the answer is specific.

Frequently asked questions

What are the stages of the app development process?

Six: discovery (deciding what to build), design (making it visible and clickable), build (writing the code), test (breaking it before users do), launch (shipping it safely), and maintenance (keeping it working). Some guides split these into seven or twelve steps, but the extra numbers are usually sub-tasks of these six. The number matters less than knowing your job in each.

How long does the app development process take?

A first real version is usually three to six months, with discovery and design taking a few weeks and the build taking the bulk. The honest answer depends on how much you cut in discovery and how often you change your mind during the build. The two levers you control sit at the front of the process, not the middle.

What is the most important phase for a non-technical founder?

The two before the build: discovery and design. That is where your leverage is highest and a change costs the least. Founders who invest their attention there and then step back during the build get better apps for less money than founders who do the reverse.

Can I skip discovery to move faster?

You can, and it is the most common way founders spend more to get less. Skipping discovery does not remove the decisions about what to build; it just moves them into the build phase, where changing them costs ten times as much. Fast starts here usually buy slow finishes.

How do I stay in control of a build I cannot technically evaluate?

Use the Handoff Test. At the end of each phase, ask for the artifact that proves it happened: a scope page, a clickable prototype, a working link, a test report, a runbook. You do not need to read code to notice when a phase ended without leaving evidence behind.