What to Cut From Your MVP: Scoping Version One

To decide what to cut from your MVP, keep only what a new user needs to reach the one result your product promises, plus anything that is very hard to add later. Cut everything else, or do it by hand for the first users. The one thing you should not cut is a clear rule for who owns each piece of data and who can see it, because adding that later means changing how every record is stored.

Most first versions are too big, not too small. The founder has a long list, and every item on it came from a real customer call. The hard part is not finding features. It is saying no to good ones. Four questions make that easier.

The four questions that decide what stays

Ask these about every item on the list, one at a time. Write the answer next to each item so the decision is on paper, not in your head.

First, can a user reach the main result without it? Picture one person signing up and getting the thing your product exists to give them. If the feature is not on that path, it can wait.

Second, would a user notice it is missing in the first week? Some features only matter after months of use, such as bulk export or detailed history. Early users will not reach them yet.

Third, can you do it by hand for now? If ten customers need a weekly report, you can write it yourself for a while. Manual work does not scale, but it does not need to yet. It also shows you what the feature should really do before anyone builds it.

Fourth, is it hard to add later? This is the question that flips the answer. Most features are cheap to add in month six. A few are not, because they live in the base of the product. Those stay in version one even when the other three answers say cut.

Why permissions and roles cannot wait

Permissions are the rules for who can see and change what. They are the clearest case of the fourth question. Every record your product saves has to belong to someone. If the first version says each record belongs to one user, and customers later ask for teams, then every record, every screen, and every check has to change.

This does not mean you need an admin panel or five roles on day one. You can ship with one kind of account. What you cannot skip is the decision underneath it. Does an account belong to a person or to a workspace? Is every request checked on the server, not just hidden in the interface? Can one customer ever reach another customer's data by changing a link?

Settle those three answers before the first screen is designed. Our guide on whether to fix or rebuild an AI MVP lists permissions added late as one of the signs that a product needs a rebuild. It is far cheaper to decide now.

What a fixed-scope MVP quote should include

A good quote describes the cut you made. It names the main flow from start to end. It gives a screen count. It lists the states each screen needs, such as empty, loading, and error. It says how many rounds of feedback are included and what you get at the end, such as design files, a clickable prototype, or working code.

It should also say how accounts and access work, even in one line. If the quote never mentions who can see what, ask. That answer shapes the whole build.

Just as important, a good quote has a list of what is out. If the quote only lists what is in, every feature you cut can come back in the middle of the project as a small extra. A written out list protects you and the studio.

What a fixed-scope MVP quote should not include

It should not include the features you already cut. It should not include loose phrases like any other screens needed, because nobody can price that. And it should not bundle a full design system or a marketing site into a first build. Our post on MVP design on a small budget covers where the money goes when funds are tight. This post is about the step before that, deciding what the money is for.

Two features founders keep that they should cut

The first is integrations. Founders often plan to connect to five or six other tools at launch, because each one came up in a sales call. Each connection is its own small product. It needs setup screens, error handling, and upkeep whenever the other tool changes. Ship the one integration your first users cannot work without. Add the rest when customers ask twice.

The second is settings. In AI products this often means a model picker, a tone slider, or a long list of options for the output. Each setting doubles the number of ways the product can behave, and every one of them needs testing. Pick good defaults instead. If users keep asking to change one thing, make that one thing a setting.

Both cuts are easy to reverse later. That is what makes them safe.

A way to run the cut this week

Put every planned feature in one list. Run the four questions against each item with whoever will build it. Mark each item keep, cut, or by hand. Then read the keep list out loud as one sentence, from sign up to result. If the sentence has more than one main verb, the list is still too long.

Where to go next

If you are choosing who to build with, our shortlist of MVP design agencies for pre-seed AI startups compares studios on what they publish. If you want to know which moment your first screens must reach, read our note on the first success moment in onboarding. And if your first version is already live, what a UX audit actually finds shows how to see where it leaks.

Studio Maydit is a web and product design studio for AI founders in the US, the UK, and Europe. We build in Framer, Webflow, or custom code, and we stay on for product design after launch. Teams like Wave, PixelFlow, and Mi-VAD have worked with us, and for Dualite, design work behind a repositioned ICP helped the product reach 100,000+ users in seven months. Work runs as a fixed scope of three to four weeks or a monthly retainer with no long lock-in. If your feature list has grown past what one version can hold, book a 30 minute call and we will go through the cut with you.