The app development process explained, phase by phase

If you've never built software, the process can look like a black box: money goes out, and months later an app appears (or doesn't). It shouldn't work that way. A good process is visible at every step.

This is how I run projects at Loha.dev, and roughly how most competent studios work. For each phase: what happens, what you get, what we need from you, and how long it usually takes (estimates, not promises).

The seven phases at a glance

Add it up and a focused first version usually lands somewhere between 3 and 6 months. Simple MVPs can be faster; apps with complex integrations, payments, or heavy compliance take longer. For a deeper breakdown of what drives those numbers, see how long it takes to build an app.

Phase 1: Discovery and strategy

Discovery is where we decide what to build and what not to build yet. Most failed apps don't fail on code. They fail because version one tried to do everything.

What happens

• Interviews about your business, your users and how you'll make money from the app.
• Listing every feature idea, then ranking them by value and effort.
• Cutting the list down to a first release that can prove the idea.
• Spotting risks early: third-party APIs, payments, data privacy, AI features, store policy issues.

Deliverables

A short product brief, a prioritized feature list with an MVP line drawn through it, a rough architecture sketch, and a budget and timeline range you can plan around.

Your role

This is the phase where you're most involved. Expect two to four working sessions. Bring examples of apps you like, any existing customer data or feedback, and the person who can make final decisions.

Typical duration (estimate): 1–3 weeks.

Phase 2: UX/UI design

Design is about how the app works first and how it looks second. UX maps the screens and flows: how someone signs up and completes the main task. UI is the visual layer: type, color, components.

What happens

• User flows for the core journeys, usually 3 to 6 of them for a first version.
• Low-fidelity wireframes to agree on structure before anyone argues about colors.
• High-fidelity screens and a small design system (buttons, inputs, cards, states).
• A clickable prototype you can tap through on your phone and show to real users.

Deliverables

Wireframes, final screen designs for every MVP screen (including empty, loading and error states, which people forget), a clickable prototype and a reusable component library.

Your role

Review designs promptly and give specific feedback ("the checkout feels like too many steps" beats "make it pop"). If you can, put the prototype in front of five potential users. It's the cheapest user research you'll ever do.

Typical duration (estimate): 2–4 weeks.

Phase 3: Architecture and tech stack

While design wraps up, the engineering foundation gets laid. It's mostly invisible to clients, but it decides how expensive the app is to change later.

What happens

• Choosing the stack: native Swift/Kotlin or cross-platform. I usually build with React Native and Expo so one TypeScript codebase ships to iOS, Android and often the web.
• Designing the data model and backend. For apps that need live updates (chat, collaboration, dashboards) I lean on realtime backends like Convex.
• Planning integrations: auth, payments, push notifications, analytics, AI/LLM providers.
• Setting up the repository, environments (development, staging, production), CI and automated build pipelines.

Deliverables

A short technical plan, a working project skeleton that builds and deploys, and accounts set up in your name (Apple Developer, Google Play Console, cloud hosting). You should own these accounts from day one, not your developer.

Your role

Create or approve the developer and hosting accounts, and make the few business decisions that affect architecture: which payment provider, whether you need offline mode, which regions your users are in.

Typical duration (estimate): 1–2 weeks, usually overlapping with design.

Phase 4: Development sprints

This is the longest phase and the one people picture when they think of "building an app." The work is split into sprints, short cycles of one or two weeks, each ending with something you can actually use.

What happens

• Each sprint starts with a short planning call: which features from the priority list go in next.
• Features get built end to end (screen, logic, backend, tests) rather than all screens first and all backend later.
• Every sprint ends with a demo and a fresh preview build on your phone.
• Scope gets adjusted based on what you learn from using the real thing.

Deliverables

Working, tested features every week or two, a preview build you can install, and a short written update: what shipped, what's next, anything blocked.

Your role

Show up to the weekly demo (30 minutes is usually enough), use the preview build, and answer questions within a day or two. Slow decisions are the most common reason projects slip, more than any technical problem.

Typical duration (estimate): 6–16 weeks for a first version, depending on scope.

How weekly demos and preview builds work

With Expo, I can push a new build of the app to your phone without going through the App Store each time. You install a preview build once, and updates arrive as we ship them. On iOS, larger builds go through TestFlight; on Android, through a Play internal testing track or a direct install link. Web versions get a preview URL for each change.

The weekly demo is a screen share plus your own hands on the app. You see real progress, not slides, and catch misunderstandings in week 3 instead of week 12.

Agile vs fixed scope: which should you choose?

There are two broad ways to contract an app build, and they change how the process feels.

My honest view: for a new product, pure fixed scope tends to backfire. Agencies pad the quote to cover unknowns, and every good idea you have mid-build turns into a negotiation. Pure open-ended agile can drift too.

What works best in my experience is a hybrid: a fixed-price discovery and design phase, then development in sprints against a budget cap and a prioritized list. You always know the most you'll spend, and you keep the freedom to swap a feature when the prototype teaches you something. If you're comparing studios, ask exactly how they handle changes; it's one of the key questions to ask an app development company.

Phase 5: QA and testing

Testing runs through every sprint, then gets a dedicated hardening period before launch.

What happens

• Real-device testing: older and newer iPhones, a spread of Android phones (screen sizes and manufacturers vary a lot), tablets if you support them, plus slow networks and offline behavior.
• Automated tests: unit tests for business logic, integration tests for the backend, and end-to-end tests for critical flows like sign-up and payment, run on every change in CI.
• Beta testing: a group of real users installs the app through Apple's TestFlight and Google Play's internal or closed testing tracks. TestFlight supports up to 100 internal testers and up to 10,000 external testers (external builds go through a light Apple review).
• Crash and error monitoring set up before beta, so problems arrive with stack traces instead of vague reports.

Deliverables

A test plan, an automated test suite running in CI, beta builds on both platforms, and a triaged bug list where every launch-blocking issue is fixed.

Your role

Recruit beta testers (customers, staff, friends who fit the target user), use the app daily during beta, and decide which non-critical bugs can wait for version 1.1.

Typical duration (estimate): continuous during development, plus 1–3 weeks of focused beta and hardening.

Phase 6: Launch

Launch means getting through store review and switching on production.

What happens

• Preparing store listings: name, subtitle, description, keywords, screenshots, preview video, privacy details and age rating.
• Submitting to Apple's App Store and Google Play. Apple review often completes within a day or two but can take longer, and rejections happen, usually over privacy disclosures, login requirements or incomplete metadata.
• Deploying the production backend, turning on monitoring and analytics, and planning a staged rollout where it makes sense.

Deliverables

Your app live in the stores (and on the web if applicable), a production environment with monitoring, and documentation and credentials handed over to you.

Your role

Supply marketing copy and assets, approve the store listings, provide the legal pieces (privacy policy, terms, support URL), and line up your launch marketing. The full walkthrough is in our guide on how to publish an app on the App Store and Google Play.

Typical duration (estimate): 1–2 weeks, including review buffer.

Phase 7: Post-launch maintenance and iteration

Launch is the start of the product, not the end of the project. Real users always do something nobody planned for.

What happens

• Fixing bugs that only show up at real-world scale or on unusual devices.
• Keeping up with yearly iOS and Android releases, SDK updates and store policy changes. An app nobody maintains will eventually break or get pulled.
• Reviewing analytics and user feedback, then running new design-and-sprint cycles for version 1.1, 1.2 and beyond.
• Monitoring hosting and API costs, especially for AI features where usage-based pricing can grow quickly.

Your role

Talk to your users, decide what matters most next, and budget for it. A common planning estimate is 15–20% of the initial build cost per year for maintenance alone, before new features.

Typical duration: ongoing, usually on a monthly retainer or in planned feature cycles.

How this process looks at Loha.dev

I run projects with the phases above, compressed where it makes sense. For an early-stage founder, our MVP development work often merges discovery and design into a tight few weeks and gets a working build onto your phone fast. For businesses replacing spreadsheets or legacy tools, custom app development spends more time in discovery mapping existing workflows.

Either way, the stack is the same: React Native and Expo for mobile app development on iOS and Android, React for the web, TypeScript, Convex and Cloudflare. It's the setup behind our own Star, a setlist and presentation app for tablets and the web.

If you'd like to see how these phases would map to your idea, get a free app plan. You'll get a suggested scope, a phase breakdown and an estimate range, with no commitment.