Building an app is less mysterious than it looks from outside, but it has more steps than most people expect. The code is only part of it. There's a backend, an admin panel, store listings, privacy declarations, testing on devices you don't own, and a review process you don't control.

Here's the journey we take, what happens at each stage, and what you should have in hand before moving on.

1. Discovery and scope

Who is the app for, and which two or three journeys matter most? A booking app might live or die on “find a slot and book it in under a minute”. Everything else is secondary. We write those journeys down, decide what's in version one, and — just as important — what isn't.

This is also when we find the hidden work: payments, maps, notifications, integrations with systems you already use, and any rules about data your industry has. You leave this stage with a short scope everyone can point at, and an estimate based on it.

2. A prototype on real phones

Before any code, a clickable prototype runs on actual devices. People tap through the key journeys with their own thumbs, and confusing flows reveal themselves in minutes. It's the cheapest moment to discover that a screen is missing or a step is unnecessary — changing a prototype takes hours; changing a built app takes weeks.

3. Design for each platform

iPhone and Android users expect slightly different things: navigation patterns, back gestures, date pickers, system dialogs, even where buttons sit. Good apps respect those expectations while keeping one recognisable brand. The design stage produces every screen in every state — empty, loading, error, offline — not just the attractive ones.

4. Build the app, the backend and the admin together

An app is rarely just an app. There's an API behind it that stores data and enforces rules, and usually an admin panel where your team manages content, users and orders. Building all three in step keeps data, permissions and features in sync. We work in short cycles, so you can install a test build on your own phone every week or two and see real progress.

5. Test on the devices people own

Your customers don't all have the latest flagship phone. Testing covers:

  • Older and lower-powered phones, and small screens.
  • Slow or dropped connections — on a train, in a lift, between Wi-Fi and mobile data.
  • Interruptions — a call arriving mid-payment, the app sent to the background and reopened.
  • Permissions denied — what happens if someone says no to location or notifications?
  • Larger text sizes and screen readers, for accessibility.

These cases are what separate an app that demos well from one that holds up in the real world.

6. Store submission and review

Both stores need developer accounts, screenshots for several screen sizes, descriptions, privacy details explaining exactly what data the app collects, and notes for the reviewer — including a test account if the app needs a login. Reviews can take a day or a week, and can ask for changes. Plan your launch date with a little room, and don't announce a launch day until the app is approved.

7. Launch, then listen

Crash reporting and basic analytics should be in place from the first release. In the first weeks, watch where people get stuck, which features they use, and what support questions arrive. Fix the biggest friction quickly — app updates are routine, and early users notice when you respond.