Process
How an app actually gets from idea to store
Five stages. The parts most people underestimate — store submission and what happens after launch — get the same attention as the build itself.
Discovery
We work out what the app has to do, who uses it, and which platforms matter first. This is also where the native vs cross-platform call gets made — before anything is designed or built.
Design
User flows first, then screens built to each platform's conventions. You tap through a clickable prototype and change things while changes are still cheap.
Build
App and backend developed together in short cycles. You get a working build on your own device at the end of each cycle — through TestFlight for iOS, the internal testing track for Android — so progress is something you use, not a status report.
Store submission
Listing copy, screenshots, app icon, privacy policy, Apple privacy labels and Google data-safety declarations. We submit, and if a reviewer rejects it we handle the response and resubmission.
Post-launch
Bug fixes from real usage, then the ongoing work: iOS and Android ship major versions every year, and Google enforces a minimum target API annually. Apps that aren't maintained stop working or get pulled.
No surprises
Things we're upfront about
- Developer accounts stay in your name. Apple's costs US$99 a year, Google's is a one-time US$25 — paid by you, owned by you.
- Store review can reject an app for reasons no one predicts. We budget time for it instead of promising it won't happen.
- Scope changes mid-build move the timeline. We'll tell you by how much before agreeing to them.
- You get the source code. It's yours at the end of the project, not held over you.
Know which stage you're at?
Whether you're at a blank page or sitting on a half-finished build, tell us where things stand and we'll pick it up from there.
