Fourteen days, from a kick-off call to an app submitted to both stores. Here is exactly how those days are spent, including the parts most agencies would rather not show you.
- Day 1
Kick-off and scope
We go through your goals, your users, and the one job the app has to do. Everything that is not that job goes on a version-two list.
- Days 2 to 3
Design
Screens, flows, and the look of the thing. You review and revise until you sign off. Nothing gets coded until you have.
- Days 4 to 10
Build
Front end, backend, accounts, notifications, admin dashboard. You see working builds as they land rather than a reveal at the end.
- Days 11 to 12
Test and fix
Real devices, real data, edge cases. This is where most of the unglamorous work happens.
- Days 13 to 14
Submit and launch
Store listings, screenshots, privacy details, and submission to the App Store and Play Store. Then 30 days of support while your first users arrive.
Day one is the day that matters
Almost all the risk in a two-week build is spent or saved on day one.
We spend it deciding what not to build. You come with a list. We work out which single job the app has to do, and everything else goes onto a version-two list. That list is not a consolation prize: it is genuinely useful, because in three months' time real users will have told you which half of it was wrong.
What we need from you
Not much, but the little we need is non-negotiable.
Your side of the sprint
- One decision-makerSomeone who can say yes without going away to ask three other people.
- Four to six hours across the fortnightKick-off, design review, a mid-build check, and final sign-off.
- Your contentLogo, brand colours if you have them, any copy or product data that has to be in the app.
- Account accessApple and Google developer accounts, or the go-ahead for us to set them up in your name.
- A reply within a working dayDuring a fourteen-day build, a three-day wait for feedback costs a fifth of the sprint.
What usually goes wrong
Honest answer, from projects we have actually run.
Design review slips. This is the big one. If day three's review lands on day six, build time is cut by three days and something has to come out of scope to compensate.
Store review timing. Apple's review usually takes a day or two, and occasionally longer over a holiday period. We submit on day twelve to leave room, but the final approval is not ours to control.
Late content. A build waiting on product photos or menu data has nothing to do with engineering and stops the sprint just as effectively.
Scope pressure late on. Around day eight, someone always remembers something. The answer is nearly always the version-two list, and it is nearly always the right answer.
After day fourteen
Your app is live, and you get thirty days of support included. That window exists because the first month is when real users find the things nobody predicted, and you should not be paying extra to fix those.
You also own everything: the source code, the repository, the developer accounts, the store listings. If you want a different developer to take it from here, nothing stops you.
Common questions
How much of my time does a sprint need?
About four to six hours across the fortnight. A kick-off call on day one, design review on day three, a mid-build check, and sign-off before submission. Miss the design review and the whole thing slips.
What happens if we're not finished on day 14?
We finish. Scope is fixed on day one precisely so the date does not have to move. If something outside our control delays it, such as a slow store review, we tell you as soon as we know.
Can I add features mid-sprint?
Not without something else coming out. Fourteen days is a fixed container. We keep a version-two list, and adding to it costs nothing.