Plans · Software
Ship a mobile app v1
14 weeks · 5 phases · 28 tasks · 5 milestones · 5 risks
For a small product team shipping a first version to the app stores. Scope is frozen in week 2, the build runs from week 4 to a feature freeze in week 11, and store review gets its own week with room for a rejection. If you don't have a backend yet, add time for it in the build phase.
Makes it a program in your harbor, dated from today.
Milestones
- Week 2Scope frozen
- Week 5Designs complete
- Week 10Beta build out
- Week 13Submitted for review
- Week 14Live in the stores
The plan, phase by phase
1. Scope
Weeks 1 to 2. Decide the smallest version worth shipping.
- Week 1Write down the one job the app must do well
- Week 1List the screens for v1
- Week 2Cut the list to what fits in 14 weeksMove everything else to a later list and don't reopen it until after release.
- Week 2Choose native or cross-platformDecide on what your team already knows well.
- Week 2Set up developer accounts on both app storesAccount verification can take a while, so start early.
2. Design
Weeks 3 to 5. Test the main flows with real people before they're built.
- Week 3Sketch the main flowsPaper or a whiteboard is fine; the point is to agree the steps.
- Week 4Test a clickable prototype with five users
- Week 5Design the screens
- Week 5Write the copy for empty states and errors
3. Build
Weeks 4 to 11. Build the core flow first and make it reliable.
- Week 4Set up the repository, automated builds and test builds
- Week 6Build sign-up and sign-inInclude password reset and account deletion; the stores may ask for them.
- Week 7Build the backend endpoints the app needs
- Week 8Build the core flowGet it working end to end on a real phone before polishing any screen.
- Week 8Add crash reporting and analyticsAdd these before beta so you see real problems from the first tester.
- Week 9Add push notifications if v1 needs them
- Week 10Handle offline and slow connections
- Week 11Freeze features
4. Test
Weeks 9 to 12. Put the app in real hands and fix what stops people using it.
- Week 9Recruit beta testers
- Week 10Ship a beta build to testersTell testers exactly what to try and how to report a problem.
- Week 11Fix crashes and blocking bugs
- Week 11Test on older and smaller phonesBorrow devices if you need to; many users don't have the latest phone.
- Week 12Run an accessibility passScreen readers, text size and color contrast.
5. Release
Weeks 11 to 14. Get through store review and watch the first days closely.
- Week 11Write the privacy policy and fill in the store privacy details
- Week 12Prepare the store listingsScreenshots, description and keywords for each store.
- Week 13Submit for store reviewLeave time for a rejection and a resubmission.
- Week 13Decide who answers reviews and support email
- Week 14Release the appRelease in stages if the stores let you, so problems reach fewer people.
- Week 14Check crash reports daily for the first week
What usually goes wrong
Scope keeps growing
Each small addition looks cheap, but together they push the release back by weeks.
What helps: Freeze scope in week 2 and keep a later list. Anything added has to replace something of the same size.
Likelihood 5 of 5 · impact 4 of 5
Store review rejects the app
A rejection close to the release date can cost a week or more.
What helps: Read the store guidelines during design, fill in the privacy details carefully, and submit a week before you need to be live.
Likelihood 3 of 5 · impact 4 of 5
The backend isn't ready when the app is
The app can't be tested properly against fake data for long.
What helps: Agree the API early and build the endpoints the core flow needs first.
Likelihood 3 of 5 · impact 4 of 5
Bugs on devices nobody tested
Screen sizes and older operating systems behave differently from the team's own phones.
What helps: Pick a list of target devices in week 2 and test on each of them before release.
Likelihood 3 of 5 · impact 3 of 5
A key developer becomes unavailable
In a small team one person often holds knowledge nobody else has.
What helps: Review each other's code and keep build and release steps written down.
Likelihood 2 of 5 · impact 5 of 5
Using it
Copy what fits and cut what doesn’t: no real project matches a template. In Harbor the plan becomes a program with these milestones, one project holding every task with its due date, and these risks in the register, all yours until you hand them out. The first phase starts in To do and the rest wait in the backlog.
Open this in HarborMore plans
- Run a round of customer research6 weeks · 23 tasksA 6-week customer research plan: research questions, recruiting, a discussion guide, interviews, synthesis and a readout with decisions.
- Migrate to a new database10 weeks · 26 tasksA 10-week database migration plan: inventory, schema mapping, sync and backfill, verification, staged cutover, rollback and decommissioning.
- Launch an open-source project8 weeks · 25 tasksAn 8-week plan to open-source a project: license, code cleanup, docs, contribution rules, community channels, launch and the first month after.