business//3 min read
Scoping an MVP: cut to one job, then build that job properly
Most MVPs are late because they are not minimum, and most fail because they are not viable. A practical way to decide what goes in, what stays out, and the few things you should never cut.
In short
- Scope around one user doing one job end to end, not around a list of features.
- Write the story of a single successful session before writing any tickets.
- Cut breadth, never depth: the one job must work reliably, securely and fast.
- Buy the commodity parts (auth, payments, email) and build only what makes you different.
Ask ten founders what an MVP is and you will hear ten versions of “the smallest thing we can launch”. The trouble is that smallest gets measured in features, and a product with fewer features is not necessarily smaller to build or easier to use. A better unit is the job: one kind of person getting one thing done, from start to finish.
Start with one person and one job
Name the person precisely. Not “small businesses” but “the operations lead at a 20-person logistics company who reconciles invoices on Friday afternoons”. Then name the job in their words: “match this week's supplier invoices to purchase orders and flag the ones that don't match.”
If you cannot write both sentences, you are not ready to scope. If you can write three different versions, pick one. The others are the next release, not this one.
Write the story before the backlog
Describe one successful session, step by step, as the user would experience it. Keep it to a page.
- She signs in with her work email.
- She uploads this week's invoices as PDFs, or forwards them to an inbox.
- The app reads each invoice and finds its purchase order.
- She sees a list: matched, mismatched, and missing a PO.
- She opens a mismatch, sees the difference highlighted, and marks it resolved or sends it back.
- She exports the matched list for the accountant.
Every screen, integration and table in the MVP must serve a line of this story. Anything that does not is a candidate to cut.
Cut breadth, never depth
The usual mistake is to keep many features and make each one shallow. Do the opposite: few features, each one finished. A user forgives a missing feature; they do not forgive the one feature they came for being slow, wrong or lost.
Cut freely | Never cut |
|---|---|
Settings pages and preferences | Correctness of the core job |
Multiple user roles | Secure sign-in and authorization checks |
Integrations beyond the one you need | Backups and a way to restore them |
Dashboards and charts | Error tracking, so you hear about failures first |
Mobile apps (a responsive web app is enough) | Basic analytics on the core job |
Buy the commodity, build the difference
Authentication, payments, transactional email and file storage are solved problems with good managed services. Building them yourself costs weeks and adds risk. Spend that time on the part only you can build: in the example above, reading invoices and matching them well.
- Auth: a managed provider or a well-tested library, never hand-rolled password handling.
- Payments: Stripe, Razorpay or your market's equivalent, with their hosted checkout first.
- Email: a transactional provider; plain, well-written templates beat elaborate ones.
- Files: object storage with signed URLs, not your web server's disk.
Fake the doors you are unsure about
Not sure people want the export to go straight into their accounting software? Add the button, and when it is clicked, show a short note that it is coming and ask what they use. You learn demand without building the integration.
Define done before you start
Agree on what success looks like for the first release in terms of the job, not the features: “a new user can reconcile a week's invoices without help in under twenty minutes.” Then test it with real users before you call it shipped.
Minimum is about scope. Viable is about quality. You need both.
Scoping checklist
- To do: One named user and one job, each in a sentence
- To do: A one-page story of a successful session
- To do: Every planned screen maps to a line of the story
- To do: Commodity parts bought, not built
- To do: Security, backups, error tracking and analytics in scope from day one
- To do: A definition of done written in terms of the job
