Most app projects do not fail at the code. They fail at the handoffs — the moment a design meets a real device, the week before submission when nobody has read the store guidelines, the month after launch when an OS update breaks a screen.

This is the process we actually run, the reason each stage exists, and what goes wrong when one is skipped.

01 — Strategy and research

Before anything is designed, we map the target users, the competitor landscape and the core feature set. The output is a decision, not a document: which platforms, and native or cross-platform.

That choice is made here because it is expensive to revisit. We use Flutter or React Native when one codebase should serve iOS and Android, and Swift or Kotlin when a fully native app is the better fit — driven by your budget, your timeline and what the app actually has to do. An app built around a platform-specific capability is a poor candidate for a shared codebase. A standard CRUD-and-API product is an excellent one.

Skip this and: you discover in month three that the feature your business case depends on needs native code you did not budget for.

02 — UX prototyping

We build interactive prototypes in Figma so you can move through the app's flows before a line of production code exists.

This is the cheapest stage at which to change your mind, by an enormous margin. Reordering an onboarding flow in a prototype costs an afternoon. Reordering it after the screens are built, wired to an API and covered by tests costs a sprint.

The prototype is also how we find the flows nobody thought about: what the app does with no data on first launch, what an error state looks like, where a user lands after completing the thing they came to do.

Skip this and: your first real design review happens against working software, and every change is a rebuild rather than a redraw.

03 — Sprint development

Two-week sprints, each ending with a build you can install — TestFlight for iOS, Firebase App Distribution for Android.

Getting the app onto your own phone early changes the conversation. Feedback on a screenshot is about the screenshot. Feedback from someone who has used the app on their commute is about the product. It also surfaces the things only a real device shows you: how the app feels on a poor connection, how it behaves when a call interrupts it, how much battery an hour of use costs.

Skip this and: you see the app for the first time when it is nearly finished, which is the most expensive possible moment to have an opinion.

04 — Device QA

Testing across real devices, OS versions and screen sizes, with automated UI tests — Detox or XCTest — protecting the critical flows against regressions.

The emulator lies. It has perfect network, unlimited battery, no interruptions and one screen size. Real devices have notches, small screens, old Android versions, aggressive battery managers that kill background work, and users who rotate the phone at the wrong moment.

Automated tests matter most for the flows that must never break: sign-up, payment, the core action of the app. Those get covered so that a routine change three months from now cannot quietly break them.

Skip this and: your one-star reviews are all from device and OS combinations you never tested.

05 — Store launch

We handle the full submission for both stores: screenshots, descriptions, review requirements and a staged rollout.

This stage is underestimated more than any other. App Store review is a genuine gate, and rejections are usually about things that have nothing to do with your code — missing account deletion, a privacy policy that does not match what the app collects, permission prompts without a clear explanation, sign-in requirements for features that do not need an account. Each round trip costs days.

Staged rollout matters too. Releasing to a small percentage of users first means a crash affecting one OS version is a rollback, not an incident.

Skip this and: your launch date becomes whatever date the third review round happens to finish.

06 — Maintenance and updates

OS updates break apps. This is not a risk, it is a schedule: iOS and Android both ship major versions every year, and each one deprecates something.

Ongoing work means proactive compatibility updates, crash monitoring with Sentry so you learn about problems from data rather than reviews, and a regular release cadence for features. Stores also enforce minimum SDK targets — an app left alone for long enough eventually cannot be updated at all without significant work.

Skip this and: your app works until the next OS release, and the cost of catching up exceeds the cost of having kept up.

How long it takes

A first release with core features usually takes between four to six weeks and three months. A full-featured app with a backend, payments and admin tools typically runs three to six months.

The variable is rarely the app itself. It is integrations with systems you do not control, content and assets that need producing, and how quickly decisions get made. Projects that move fast are the ones with a single decision-maker available every week.

Where to start

You do not need a specification. You need the problem, a sense of who it is for, and someone able to make decisions.

We start with a free scoping session, and a proposal with phases and costs follows within three to five business days. We built and shipped Zipp Drive — two apps, both stores — through exactly this process.

Book a free consultation and we will map your idea to a realistic first release.