Mobile App MVP Planning: Deciding What Goes in the First Release
A mobile MVP should include the smallest set of features that lets a real user complete the core task end to end,…
State the objective in measurable terms
A brief asking for a modern, professional site gives a developer no basis for any decision, so decisions get made on aesthetic preference and then revised when someone realises the site does not do what the business needed.
Objectives should be measurable: increase qualified enquiries from organic search, reduce support calls by publishing self-service documentation, shorten the sales cycle by making pricing and specifications accessible. Each implies different structure, different content and different measurement.
- What business outcome should improve, and by roughly how much
- How that outcome is currently measured and what the baseline is
- Which audiences matter and what each needs to accomplish
- What action counts as success on each key page
- What is currently failing on the existing site, with evidence
Content is the usual reason projects slip
Design and build run to a plan. Content does not, because it depends on people who have other jobs. The predictable failure is a site technically complete in week ten and launched in week twenty-two while waiting for copy that nobody was formally assigned to write.
The brief should name who produces each content type, by when, and who approves it. Where the client cannot commit to that, commissioning content as part of the project is cheaper than the delay, and considerably cheaper than launching with placeholder text that stays for a year.
| Item | Decision needed |
|---|---|
| Page inventory | Which pages exist at launch |
| Content owner | Named person per content type |
| Delivery dates | Per batch, ahead of the build stage that needs it |
| Approval authority | Who signs off, and their deputy |
| Imagery | Photography commissioned, stock, or existing library |
| Migration | Which existing content moves, changes or is retired |
Technical and integration requirements
List what the site must connect to and what must be preserved. Integration requirements discovered mid-build are the most expensive category of change, because they frequently affect architecture rather than just adding a feature.
Preservation requirements matter equally. Existing URLs, search rankings, tracking history, accessibility compliance and any hosting or data residency constraints should all be stated, since a rebuild that silently changes every URL loses accumulated search visibility that took years to build.
- Systems to integrate with: CRM, ERP, payment, marketing automation
- Existing URL structure and redirect requirements
- Analytics and conversion tracking to preserve
- Accessibility standard to meet
- Hosting, performance and data residency constraints
- Who administers content after launch and their technical level
Approval process and revision limits
Name the decision maker and their deputy, and state how many revision rounds are included at each stage. Projects where approval passes through an undefined group of stakeholders accumulate contradictory feedback and revise indefinitely.
Consolidating feedback through one named person is not bureaucracy. It is the mechanism that prevents a designer receiving three mutually exclusive instructions in the same week.