Founders often bring us a feature list for an MVP that would take a year to build. The fix is not to build faster; it is to build less of the right thing.
Find the one job
Write one sentence: “[Customer] uses [product] to [job] instead of [current workaround].” Every feature in the MVP must directly serve that job. Everything else goes on a later list.
What an MVP still needs
- Secure sign-up, login and roles.
- The core workflow, done well.
- Billing, even if it is simple.
- Basic analytics so you can see what people actually use.
- Backups, monitoring and error tracking.
What can wait
- Integrations beyond the one or two your first customers insist on.
- Custom reporting and dashboards.
- Mobile apps, if the web app works on phones.
- Admin tools you can temporarily replace with direct support.
A realistic MVP plan
| Week | Focus |
|---|---|
| 1–2 | Customer interviews, the one-job statement, clickable prototype |
| 3–4 | Validate the prototype with 5–10 target customers; cut scope |
| 5–10 | Build the core workflow, sign-up, billing and analytics |
| 11–12 | Private beta with paying or committed early customers |
Technology choices that keep options open
- A mainstream stack with a large talent pool, such as TypeScript with React or Next.js and PostgreSQL.
- Multi-tenancy designed in from the start, even if you have one customer.
- Managed hosting and services, so the team builds product instead of servers.
- Clean APIs, so mobile apps and integrations can be added later without a rewrite.
If nobody is upset that a feature is missing, it was not part of the MVP.
