Insights · Process · 5 August 2026
How a v1 ships in twelve weeks
Twelve weeks is enough to take an app from a one page brief to the App Store. It is not enough to waste any of them. Here is where the weeks actually go.
Week twelve, Friday afternoon. The app is in the store, the first real users are in it, and the founder is reading actual behaviour instead of guessing. Rewind the tape: what had to happen, week by week, for that Friday to exist?
This is the anatomy of a twelve week build as we run it. Not a methodology with a trademark, just the calendar of a version one that ships, written down so you can hold any team, including us, to it.
Week zero: the one page brief
Before the clock starts, we agree a one page brief: who the app is for, the single job it does, and what number tells us it worked. One page is not a compromise, it is a feature. If the idea does not survive compression to a page, twelve weeks of building will not save it.
The page also names the cut list from day one: the features everyone agrees are version two. Writing them down early is what makes cutting them later painless, because nobody is losing an argument. They are following a plan they signed.
Weeks one to three: a skeleton that runs
Something installs on your phone in week one. It is ugly and it is real: the main loop wired end to end, with placeholder everything. A prototype you can hold answers questions no document can, and it starts the Friday rhythm that carries the whole project.
By week three the skeleton has its spine. Navigation is settled, data flows, and the one loop works badly. Working badly early is the goal. Every week after, it works less badly, and everyone can see exactly which week they are in without reading a status report.
Weeks four to eight: demos, flags, and honest scope
Every Friday, working software, no slides. Anyone on either side can look at the build and know the truth of the project, which is precisely what slide based status meetings exist to soften.
New code ships behind feature flags, so half finished work never blocks a release and risky ideas can be tested on a few users before they reach everyone. Scope changes are welcome through this whole stretch, priced in writing before they are built. The deadline stays honest because the scope conversation never stops being explicit.
Week eight: the cut conversation
Somewhere around week eight, the cut conversation happens on schedule. Whatever is not going to be great by launch moves to the version two list that was written in week zero. This is the moment weak projects skip and strong projects keep.
Shipping a smaller app that feels finished beats shipping the whole plan at eighty percent finished. Every strong first version you admire made this exact trade, whether or not its makers admit it.
Weeks nine to twelve: launch is a checklist, not a leap
The final stretch belongs to the store and the instruments: listings and screenshots, review submission, crash reporting, and the analytics that measure the number from the brief. Nothing in this stretch is dramatic, which is the point. Drama at launch is what week four negligence looks like when it finally surfaces.
Then the interesting part begins. The first month of real usage tells everyone what version two actually is, and it is rarely what anyone predicted in week zero. The plan was never the point. The learning was, and now it runs on its own.
What this asks of you
A build like this needs three things from the client side: one person empowered to decide, answers inside a day when a decision blocks the build, and an hour on Fridays to look at the truth. Given those, twelve weeks is not a heroic deadline. It is just a calendar, followed in public.