What counts as an MVP
An MVP is a real, installable app that does one job well enough for early users to rely on it. It is not a clickable prototype and not a feature-complete product. Its purpose is to learn whether people want the product before you invest in everything else.
Where the time goes
| Stage | What happens | What makes it longer |
|---|---|---|
| Discovery and scope | Define the user, the job, the screens and the release target | Undecided product questions |
| UX and screens | Flows, wireframes, key screens, Flutter theme | Fully custom design on every screen |
| Build | Flutter app in short iterations with installable test builds | Backend, payments, integrations, multiple roles |
| Testing | Unit tests on risky logic, device testing | Many device-specific features |
| Store release | Listing, privacy policy, Data safety, review | Rejections; new developer accounts that need closed testing first |
What fits in a weeks-long MVP
- One user type and one core workflow
- Standard navigation and components with a branded theme
- Offline-first, or Firebase Auth and Firestore for accounts and sync
- Crash reporting, analytics and remote configuration from day one
- One store at launch
What pushes an MVP to months
- Several user roles with different screens and permissions
- Payments, subscriptions and the server-side validation they need
- Custom backend infrastructure instead of managed services
- Real-time features, messaging or complex integrations
- Launching on both stores with full parity on day one
An example from our own products
CropFlow, our photo cropping app, is a single-screen tool: import, crop, straighten, preview and export. It needed no backend and shipped with our shared remote configuration and update prompts built in. It reached version 1.0.7 within weeks of its first Play release, because the scope was small enough to ship and then improve in small releases.
How to keep the MVP timeline short
- Decide the product questions before the build starts
- Keep a written 'not now' list so scope does not creep quietly
- Prepare the store account, privacy policy and listing assets in parallel with the build
- Use test builds to make decisions on a real app, not on documents
