Most explanations of the app development process are either a textbook waterfall diagram or a vendor's sales funnel wearing a lab coat. Here's the version we actually run — seven steps, what happens inside each, and the red flags that tell you a process is going to eat your budget and calendar.
1. Define the product — in five lines
Before anything gets designed, the product has to fit in five sentences: the idea, the user, the screens that matter, the brand, the ship date. This isn't a formality — it's the test that the thinking is done. A product that needs forty pages to explain isn't defined yet; it's deferred.
2. Design — just ahead of the build
Design the core flows first at real fidelity — the two or three screens the product lives or dies on — and let the rest follow during the build. The old pattern of "finish all designs, then start coding" doubles your calendar and guarantees the designs are stale by the time they're built.
3. Choose the boring architecture
Stack choices should be dull: proven framework, managed backend, bought auth and payments. Every custom-built solved problem is money that didn't go into the product. The interesting decisions are product decisions; the infrastructure should be the most boring thing about your app.
4. Build in weekly sprints
The build runs in fixed-scope weekly cycles, and every week ends with working software you can touch — a TestFlight build, a staging URL, not a slide deck. This is also the step AI transformed: boilerplate, wiring, and tests now move 2–5× faster under a small senior team, which is why the whole process fits in weeks instead of quarters.
5. Harden on real devices
Then the unglamorous week that separates products from demos: bad networks, empty states, interrupted flows, older devices, the one keyboard that covers your submit button. AI writes code; it doesn't hold forty phones. Skipping this step is how apps meet their first users through one-star reviews.
6. Launch — with a buffer
Store listing, analytics, crash reporting, and review submission. App Store review usually clears in a day or two, but first submissions bounce often enough that a one-to-two-week buffer before any public date is just adult planning. Soft-launch first: real users, small blast radius.
7. Iterate — the step that never ends
Version 1.0 is the beginning of the product, not the end of the project. Budget 15–20% of the build cost per year for OS updates, fixes, and the improvements real usage demands — and treat the first month's analytics as the true spec for version 1.1.
A good process produces working software every week. Everything else it produces is overhead.
Red flags in a partner's process
- A long discovery phase billed before anything is built. Definition should take days, not months.
- No weekly demo. If progress arrives as reports instead of software, assume the worst.
- Hourly billing on a vague scope. That's a blank check with a logo on it.
- They keep the keys. Your repos, your store accounts, your infrastructure — from day one.
- Everything is possible. A partner who never says "cut this" isn't protecting your ship date.
How we run it
This is the process behind everything we ship — our own apps and games included. It starts with your five lines, prices as a fixed scope, demos every Friday, and holds the date by cutting scope instead of slipping. If you want to see step 1 happen to your idea, send us the five lines — the brief costs nothing and usually teaches you something about the product either way.