How to scope an MVP: what to build first, and what to leave out

Most first versions of a product are too big. Not because anyone planned it that way, but because every feature sounds reasonable on its own: users will expect a login, an admin panel, notifications, reports, a mobile app. Add them up and the "minimum" product takes nine months instead of three, and you still don't know whether anyone wants it.

A minimum viable product is the smallest thing that lets a real customer get real value, so you can learn whether the idea works. Scoping one well is mostly about deciding what not to build yet. Here's the process we use.

1. Write down the one job the product does

Start with a single sentence: who it's for, what they're trying to get done, and what changes for them when it works.

Small accountancy firms can collect documents from clients without chasing them by email.

If you can't write that sentence, you're not ready to scope features. If you have three sentences, pick one. The others can be the second and third releases.

2. Walk through the journey, start to finish

List every step the customer takes to get that one job done, from first arriving to getting the result. For the example above:

1. The accountant invites a client
2. The client sees what's needed and uploads documents
3. The accountant sees what's arrived and what's missing
4. The client gets a reminder for anything missing

Every feature in the MVP should exist to make one of these steps possible. Anything that doesn't map to a step waits.

3. Sort every idea into now, next or later

Put each feature idea into one of three columns:

• Now: the journey doesn't work without it
• Next: it makes the journey better, faster or nicer
• Later: it's a different journey, a different customer, or a guess

Be strict. Password reset is now if people need to log in. A dashboard with charts is almost always next. Integrations with five other tools are usually later: start with the one your first customers use most.

4. Do the expensive parts by hand first

Some features are expensive to build but cheap to do manually while you have a handful of customers. Onboarding, billing, reporting and data clean-up often fall into this group.

If the accountant needs a monthly summary, an email you send by hand for the first ten customers costs an hour a month. A reporting module costs weeks. Build it when doing it by hand starts to hurt, and by then you'll know exactly what the report should contain.

5. Decide what "working" means before you build

Agree up front what you'll measure and what result would tell you the idea works. For example: ten firms invite at least five clients each in the first month, and half of those clients upload without being chased.

This does two things. It keeps the scope honest, because every feature has to help you reach that number. And it means the launch ends in a decision, not just a release.

6. Write the spec, then cut it once more

Turn the now column into a written spec: each step of the journey, what the user sees, what happens behind the scenes, and what "done" looks like for each piece. Then read it again and ask, for each item, "would a customer refuse to use this without it?" Anything that survives that question stays.

A good MVP spec is short enough that everyone involved can read all of it, and specific enough that two engineers would build roughly the same thing from it.

Common mistakes

• Building for scale you don't have. You don't need infrastructure for a million users to serve your first fifty. Choose tools that can grow, but don't build for growth yet.
• Designing every screen. Polish the steps customers use every day. Admin screens can be plain.
• Skipping the boring essentials. Backups, error monitoring and a way to recover a forgotten password are small, and painful to be without.
• Treating the MVP as a throwaway. Scope it small, but build what you do build properly, because successful MVPs become the product.

How this works in the Lab

In the Lab, you write the brief in your own words: the problem, who has it and what done looks like. AI drafts the spec and task list from it, our engineers refine them, and you approve the plan or send it back before any code is written. Changes later go through a change request you approve, so the scope only grows when you decide it should.

If you have an idea and want help cutting it down to a first version, tell us about it or read more about our software development work.