# Mobile Project Planning

> Expert guidance on scoping a mobile application, cutting an MVP, prioritizing platforms, and sequencing milestones. Use this when a project is starting or a major feature set is being defined.

- Skill: `almasumdev/mobile-project-planning` (Agent Skill)
- Install (CLI): `npx skillmds@latest add almasumdev/mobile-project-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/almasumdev/mobile-project-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: almasumdev (https://skillmd.com/u/almasumdev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/almasumdev/mobile-project-planning

---


# Mobile Project Planning

## Instructions

Mobile projects fail most often from unclear scope and mismatched platform expectations, not from coding mistakes. Use this skill to turn a product idea into a buildable plan before any architecture or code decisions are locked in.

### 1. Capture the Problem, Not the Screens

Start with three artifacts, in this order:

1. **Job stories** -- "When <situation>, I want to <motivation>, so I can <outcome>." One sentence each, no UI words.
2. **Top-level KPIs** -- what metric proves the app is working (D7 retention, conversion, session length, completion rate). One primary, two guardrails.
3. **Non-goals** -- written explicitly. What the app will *not* do in v1.

If the team is drafting screens before these exist, stop and back up.

### 2. Define the MVP Cut

An MVP is the smallest app that lets a real user get the core outcome end-to-end. Use the cut checklist:

- **One happy path** end-to-end. No branches.
- **One persona**. Secondary roles come later.
- **One platform** (usually the one your target users skew toward).
- **Manual ops are allowed**. Admin consoles, CSV uploads, and humans in the loop are valid MVP substitutes.
- **Paywall, auth, and onboarding** can often be simplified or stubbed for v1 if the KPI does not depend on them.

Write an MVP spec that a stranger could read in 10 minutes.

### 3. Prioritize Platforms

Pick a launch order, do not try to ship both platforms simultaneously unless a cross-platform stack is chosen and staffed for both.

| Signal | iOS first | Android first | Both simultaneously |
| --- | --- | --- | --- |
| Target market demographics | High-income, US/UK, premium | Emerging markets, mass-market | Regulatory or enterprise launches |
| Team skills | Swift/SwiftUI heavy | Kotlin/Compose heavy | Flutter/RN/KMP with parity budget |
| Monetization | Premium subscription, high ARPU | Ads, freemium, low ARPU | Enterprise with contractual SLAs |
| Device fragmentation cost | Low (fewer SKUs) | High (budget for QA) | Accepted explicitly |

Document the decision with one paragraph of reasoning in the project README.

### 4. Milestone Sequencing

A mobile plan sequences five tracks in parallel, not one linear backlog:

1. **Product spine** -- the critical happy-path flow.
2. **Platform plumbing** -- auth, storage, networking, crash reporting, analytics.
3. **Release pipeline** -- CI, signing, internal testing track, stores.
4. **Compliance** -- privacy labels, permissions copy, export compliance.
5. **QA assets** -- device list, test plan, beta cohort.

Every milestone should move all five forward. Avoid milestones that only ship product spine, because the others then block launch.

### 5. Estimation Heuristics

- A screen with real data, empty state, error state, and tests is typically 2-5 engineer-days per platform, not per project.
- Every third-party SDK adds review, privacy, and binary-size cost. Budget half a day per SDK for integration plus ongoing maintenance.
- First store submission typically takes 1-2 weeks of calendar time for review, metadata, and iteration on rejections. Include this explicitly.

### 6. Deliverables From Planning

At the end of planning, the agent should produce:

```markdown
# Product One-Pager
- Job story (primary): ...
- Primary KPI: ... (target: ...)
- Guardrail KPIs: ..., ...
- Non-goals: ...

# MVP Scope
- In: ...
- Out: ...
- Manual workarounds: ...

# Platform Plan
- Launch platform: iOS | Android | both (stack: ...)
- Follow-on platform ETA: ...

# Milestones (6-8 weeks)
- M1: spine screens + auth stub + CI green
- M2: persistence + offline read + crash reporting
- M3: store pipelines + internal beta
- M4: payments or core monetization
- M5: public launch readiness
```

### 7. Anti-Patterns to Refuse

- "Let us ship everything in the roadmap as v1." Force a cut.
- "We will decide platform later." Decide now; revisit in writing.
- "Designs first, scope later." Scope first; designs serve the cut.
- "We will do QA at the end." Plan QA into every milestone.

## Checklist

- [ ] Primary KPI and guardrails are named and measurable.
- [ ] MVP fits on a single page and covers one persona on one platform.
- [ ] Launch platform is documented with rationale.
- [ ] Five parallel tracks are represented in every milestone.
- [ ] Third-party SDK count is explicit with per-SDK justification.
- [ ] Non-goals list exists and is referenced in planning reviews.
- [ ] Estimation accounts for store review latency.