Six Weeks From Brief to Store: The Fine Print
Pavlo Rubanovskyi
May 29, 2026 · 6 min read
The number, and why it is not an answer
Our average delivery is six weeks from brief to a live store listing. Agencies quote numbers like this constantly and they are close to useless on their own, because the estimate is never really about engineering speed. It is about how many unknowns are still open when the work starts.
So here is the same number with its assumptions attached. If yours differ, the estimate moves — and you will be able to see why.
What six weeks assumes
One decision-maker, reachable within a day. This is the single biggest variable, and it is not a technical one. A design question that waits four days for a committee costs four days. Across a build, approval latency routinely outweighs every optimisation we could make in the code.
Scope fixed at the end of discovery. Discovery ends with an architecture plan, a scope document and a roadmap. Changes after that are welcome, but they are re-scoped rather than absorbed — a feature added silently in week four is a deadline moved silently in week six.
One platform pair, no bespoke backend. Flutter to iOS and Android from one codebase, with Firebase or a straightforward REST API behind it. A custom backend, an admin panel or a third integration is separate work with its own timeline.
Content and accounts exist. Store accounts, a privacy policy URL, app icons, real copy. These are trivial individually and reliably late as a group. We have watched a finished build sit for a week waiting on a Developer Program enrolment.
What the six weeks contains
| Stage | What comes out of it |
|---|---|
| Discovery | Architecture plan, scope document, roadmap |
| Build | Production code, weekly demos, knowledge base |
| Quality assurance | QA report, store-compliance check, performance profile |
| Delivery | Store launch, automated CI/CD, full code ownership |
Weekly demos are not a courtesy. They are how scope drift becomes visible in week two instead of week five, and they are the reason the estimate holds as often as it does.
What breaks it, in order of how often
1. Store review. Outside our control and genuinely variable. A rejection on metadata or privacy grounds can add a week — which is precisely why the compliance check sits inside quality assurance and not after it. 2. Late scope. Not the size of the change; the timing. The same feature costs little in week one and a great deal in week five. 3. Approval latency. See above. It is the cheapest thing on this list to fix and the one most often left unfixed. 4. Third-party dependencies. A payment provider's onboarding, a partner's API, a legal review. Each has a queue you do not control.
Getting a real number for your project
We would rather scope than estimate blind. The most useful thing you can bring to a first conversation is not a specification — it is a clear answer to three questions:
- Who signs off, and how fast?
- What is the one thing this must do to be worth shipping?
- What already exists — designs, backend, store accounts, content?
With those, an estimate is engineering. Without them, it is a guess with a confident number attached, and you should treat any agency's timeline accordingly, including ours.