How to Scope an MVP: The 4-Column Method We Use With Founders

You've got a SaaS idea and a Notion page with 43 features on it. Two agencies quoted you five and seven months. You tried cutting the list yourself over a weekend, and it barely moved, because every feature feels like the one a customer will ask for on day one. So you're stuck between two fears: spending your savings on something nobody uses, or launching something so thin it looks like a school project.

"Focus is about saying no."

Steve Jobs, Apple Worldwide Developers Conference, 1997

Here's how to scope an MVP without guessing. It's the same method we run with founders before we write any code, and it usually turns that 43-line list into something we can ship in weeks.

Start with one sentence, not a feature list

Before anyone opens Figma, we ask the founder to finish this sentence:

"A [specific person] can [do one thing] and we'll know it works when [something we can count]."

For a booking tool for dog groomers in Austin: "A groomer can take a deposit for an appointment without a phone call, and we'll know it works when 10 groomers take 50 paid bookings in a month."

That sentence does most of the scoping for you. Reports, team accounts, a mobile app, dark mode, integrations with five calendars? None of them help a groomer take a deposit. They can wait.

If you can't write the sentence, you're not ready to scope. You're still deciding what the product is, and no feature list fixes that.

Draw the system before you list features

The second thing we do is draw. A whiteboard or a sheet of paper is fine. We map three things:

1. The main job. What the product has to do for the user, in their words.
2. What connects to what. Payments, email, a calendar, an existing CRM, an admin who approves things.
3. Who keeps it running. Who answers support, who fixes a broken booking at 9pm on a Saturday.

This catches the stuff a feature list hides. Our groomer tool needs Stripe, a confirmation email and someone to refund a no-show. Nobody wrote "refunds" on the list. Everybody needs it by week two.

The four-column scoping table we use

Now take every feature on your list and put it in one of four columns. This is the part most guides skip. They split features into "must have" and "won't have", and then everything in the first pile gets built in code. You don't have to.

Two rules keep the table honest:

• Build has 3 to 5 items, max. If it's longer, your sentence is too broad.
• Anything you'd do fewer than 20 times a month goes in "Do by hand". A founder refunding 3 bookings a week learns more about their customers than a refund screen ever will.

The Automate column is where we save founders the most time. Reminder emails, lead routing, a weekly CSV export, a welcome sequence: we build these in GoHighLevel, n8n or Make in days, and they're easy to replace with code later if the product takes off. We do a lot of this on our AI and automation work, and it's often the difference between a 6-week build and a 4-month one.

Ask "what breaks if we wait?" for every feature

When a founder fights to keep something in Build, we ask one question: what breaks if this ships 6 weeks after launch?

• "Users can't sign up." That's real. Keep it.
• "A big customer might want SSO." Might. When that customer shows up with a contract, you'll build SSO in a couple of weeks and they'll wait.
• "It looks unprofessional without it." Sometimes true. Usually that's about polish on the core flow. Give it to your designer and keep the feature list where it is.

Write the answers down. In a month you'll want to remember why you said no.

Scope the boring parts too

Thin MVPs rarely fail because of a missing feature. They fail because the basics feel shaky. So these stay in scope even when everything else gets cut:

• Sign up and log in that work on a phone.
• Payments through Stripe or a similar provider, never home-built.
• A page that loads in under 2 seconds. It's the target we set on every site and app we build.
• Error messages a human can read.
• A short handover doc explaining how it's put together, so the product isn't stuck with one developer.

None of this is exciting. It's exactly what makes a small product feel trustworthy.

Plan for version two on day one

Here's a story that shows why. When Rezaid Film Manager, a film production SaaS, came to us, the product was built and in testing. It worked. But it had been built feature by feature with no architecture to grow on, and the team was about to add more. Wasif, our CEO, owns the architecture now and led a rebuild on the MERN stack (MongoDB, Express, React, Node) so new features don't fight the old ones.

So yes, keep the MVP tight. Just keep a sketch of where it's going next to it. We keep a one-page "later" list next to the scope: the features you cut, in the order you expect to add them. The code gets structured so those can slot in without a rewrite. It costs a day of thinking at the start, which is a lot cheaper than the rebuild Rezaid needed.

Write the scope so your developer can't misread it

A good MVP scope fits on two pages. Ours always includes:

1. The one-sentence test from the top of this post.
2. The system sketch.
3. The four-column table.
4. What "done" means for each Build item, written as something a user does ("a groomer can change an appointment time") rather than a technical task.
5. The later list.
6. A change rule: new ideas go on the later list, and anything that moves into Build pushes something else out.

That last rule matters more than people think. Scope creep is how a 6-week build turns into 5 months, one "small addition" at a time.

Where copy fits in

Founders forget that an MVP has words on it. When we launched FilingExpress, a filing service that needed to look trustworthy on day one, we wrote the landing copy around the actual filing steps and the questions customers ask at each one. That copy sat in the scope from the first week. Put your landing page, onboarding emails and empty-state text in the Build column. Users judge the product by them before they touch a feature.

How long a well-scoped MVP takes

With 3 to 5 Build items, the boring basics and automation handling the rest, most MVPs we scope land in weeks rather than months. The exact number depends on the Build column, which is why we never quote a timeline before the table exists. If you want to see how scope drives price, our app development cost guide breaks down what each tier of build costs.

FAQs

What should be included in an MVP?

The one workflow that proves your idea, plus sign up, payments if you charge, a fast page and readable errors. Everything else is automated, done by hand or cut until users ask for it.

How many features should an MVP have?

We aim for 3 to 5 custom-built features. If your list is longer, your one-sentence goal is probably too broad. Narrow the user or the job first.

What's an example of a good MVP scope?

A booking tool where groomers take a deposit online. Build: the booking page and the deposit. Automate: reminders and alerts. By hand: refunds and onboarding. Cut: dashboards, team roles and a native app.

If you'd like a second pair of eyes on your list, our SaaS development team has scoped and shipped MVPs across more than 1,000 projects. Send us your feature list and we'll tell you what we'd build first.