The 10-step preparation checklist
A useful project brief is not dozens of screen drawings; it is a problem definition that enables decisions. With these 10 outputs ready, scope, risk and delivery order can be settled before any code is written.
| Step | Output | Why it matters |
|---|---|---|
| 1 | One-sentence problem | Fixes the need rather than the solution |
| 2 | Primary user | Prevents designing for everyone |
| 3 | Single primary flow | Defines the working core of the MVP |
| 4 | Out-of-scope list | Stops silent scope growth |
| 5 | User roles | Shapes permissions and the data model |
| 6 | Integration inventory | Makes external dependencies visible |
| 7 | Content and data source | Clarifies who supplies what |
| 8 | Success criterion | States what launch will validate |
| 9 | Account ownership | Keeps stores and infrastructure in the owner's name |
| 10 | Acceptance criteria | Defines when delivery is complete |
Define the problem without a feature list
The problem sentence should identify the user, current behaviour and obstacle. “We want a mobile app” is not scope; “the field team cannot complete a service record before returning to the office” produces design and engineering decisions. Features come after that sentence.
A good problem statement does not prescribe the solution; it states which user cannot complete which job and why.
Write the primary flow and exclusions together
For an MVP, the primary flow is one chain from opening the app to seeing a verifiable outcome. In DrapeAI that chain was upload a photo, choose a garment and see the result. Social sharing, advanced profiles and secondary filters were unnecessary for the first validation.
- Describe the primary flow in no more than 5-7 user steps.
- For every extra feature, ask how it contributes to the tested assumption.
- Do not lose excluded ideas; keep them in a separate out-of-scope list.
- Do not automatically treat an admin panel, multiple languages and advanced reporting as mandatory.
Roles and integrations drive scope before screen count
User roles and external integrations are the two fastest scope multipliers in a mobile app. If an end user, administrator, field worker and business owner see the same record differently, you need a permission matrix. If the app uses payments, maps, ERP, identity or an AI service, document accounts, quotas and failure paths upfront.
| Integration question | Expected answer |
|---|---|
| Who owns the service? | The product owner's account or explicit responsibility |
| Is there a test environment? | Sandbox access and sample data |
| What happens when a request fails? | A user-visible fallback path |
| Is there a quota or usage cost? | A monthly limit and warning threshold |
| Which data is shared? | Explicit fields and a retention decision |
Separate success from acceptance criteria
A success criterion evaluates the product assumption; an acceptance criterion evaluates delivery. “Test users complete the primary flow without help” is a success criterion. “The form must not lose data offline and must submit after reconnection” is a testable acceptance criterion.
Who should own store and infrastructure accounts?
Apple Developer, Google Play, domain, analytics and cloud accounts should be opened in the product owner's legal or individual name. Everyone who works on the product gets role-based access; passwords and ownership are not shared. This keeps control of publishing and data with the owner even when people change.
Questions
- Do I need finished designs before starting a mobile app?
- No. Finished screens are unnecessary at the start; a problem statement, target user, primary flow and reference products are enough. User flows and interface design can follow during discovery.
- How many screens should I define before development starts?
- Define user steps before screen count. The same screen can create very different workloads because of roles, states and error scenarios. A primary flow, role list and integration inventory make the workload far easier to estimate.
- How detailed should a mobile app MVP be?
- An MVP should be complete enough to test one risky assumption with real users. The primary flow must work, data must not disappear and core failure states must be handled; secondary features, advanced reporting and scale optimization can wait.