MVP Scope: Cutting Your App Down to What Ships in 4 Weeks

Most first apps are too big. The founder lists everything the product will one day do, a developer prices it, and the number and timeline are both scary. Good MVP scope works the other way round: start from the one job a customer is paying you to do, build only what that job needs, and do everything else by hand or not at all. Done well, most first versions fit into about four weeks of build time. This guide gives you a repeatable method for cutting your feature list, a worked example from 23 features down to 8, and a short list of things you should never cut.

Why smaller is safer

A smaller first version is not about being cheap. It is about finding out whether you are right, sooner.

CB Insights' March 2026 analysis of 431 venture-backed startups that shut down found that 43% cited poor product-market fit, and 70% ran out of capital (companies often had more than one reason). Those two go together. Spend your budget building features before you know what customers value, and you can run out of money before you learn the answer.

Features are also less valuable than they look on a whiteboard. Pendo's 2019 Feature Adoption Report analyzed usage across 615 of its customers' software products and found that "80 percent of features in the average software product are rarely or never used." Your list will have its own 80%. The goal of scoping is to guess which features those are before you pay for them.

Finally, unclear scope is expensive in its own right. The Project Management Institute's 2014 Pulse of the Profession research found that when projects miss their original goals, inaccurate requirements management is the primary cause almost half the time (47%).

Step 1: Write the one-sentence promise

Before you touch a feature list, write one sentence:

For [specific customer], who [specific problem], our app [does one thing] so that [measurable outcome].

For example: "For independent dog groomers who lose bookings to missed calls, our app lets clients book and pay a deposit online so that no-shows and phone tag drop."

If you cannot write this sentence, you are not ready to scope. Go back to customers. See how to validate an app idea before you spend money.

Step 2: Map the core journey

Write the steps a customer takes to get the outcome in the sentence, from first visit to done. Keep it to 5 to 10 steps.

For the groomer app:

1. Client opens the groomer's booking link.
2. Picks a service and a time slot.
3. Enters their details and their dog's details.
4. Pays a deposit.
5. Gets a confirmation and a reminder.
6. Groomer sees the booking on their schedule.

Every feature in your MVP should support a step in this journey. Anything that does not is a candidate to cut.

Step 3: List everything, then sort it

Now write the full wish list, without judging it. Then put each feature through four filters, in this order.

1. Can it be done by hand for the first 50 customers? Onboarding, refunds, reporting and support can often be a person with a spreadsheet and an inbox.
2. Can an existing tool do it? Payments (Stripe), email (a sending service), scheduling calendars, help desks and analytics are all off the shelf.
3. Do only some users need it? Features for power users, edge cases and rare roles can wait.
4. Is it for scale you do not have yet? Multi-location support, complex permissions, advanced reporting, localization.

If a feature survives all four filters, it is probably core.

Worked example: from 23 features to 8

Here is the groomer app's full wish list, put through the filters.

The result: 8 features to build (with basic branding folded into the booking page), a few handled manually, and a clear list for version two. That is a first version a small team can realistically build, test and launch in about four weeks. The 23-feature version might take several months and cost several times as much, before you know whether groomers will pay.

Notice what did not make the cut: native iOS and Android apps. A mobile-friendly web app gets the booking link into clients' hands on day one. For the full decision, see web, iOS or Android first?

What you should never cut

Scoping down is not the same as cutting corners. Keep these in every MVP:

• Secure authentication. Proper login, password resets and session handling. The OWASP Top 10 for 2025 ranks "Broken Access Control" as the top web application security risk.
• Data protection. Encrypt data in transit, restrict who can see what, and back up the database.
• Error handling and monitoring. You need to know when something breaks, before your customer tells you.
• Store rules if you ship to the App Store. For example, Apple's guideline 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app."
• Privacy policy and terms. Required by app stores and payment processors.
• A way to reach you. A support email or contact form.

How to fake it well

Some of the best MVP features are not software at all. Common "manual first" patterns:

• Concierge onboarding. You set up each new customer's account yourself on a call. You learn what confuses them.
• Spreadsheet reporting. Export the data weekly and email a summary. Build the dashboard once you know which numbers people look at.
• Manual matching. In a marketplace, you pair buyers and sellers by hand until the patterns are clear.
• Human support instead of a help center. Answer every question personally. Your FAQ writes itself.

Tell users what is manual if it affects them. "We will confirm your booking within an hour" is honest and fine.

Write the scope down

A scope that lives in your head is not a scope. Write a one to two page document with:

1. The one-sentence promise.
2. The core journey steps.
3. The in-scope feature list with a line each on what "done" means.
4. The out-of-scope list, explicitly. This is where most arguments are prevented.
5. Platforms: web, iOS, Android, or which combination.
6. Integrations: payments, email, maps, anything else.
7. What you will handle manually.

We have a full template in how to write an app brief a developer can actually quote.

Protecting scope during the build

Scope creep is rarely one big change. It is ten small ones that each sound reasonable. Three habits help:

• Keep a "later" list and add every new idea to it. Promise yourself you will look at it after launch.
• Trade, do not add. If something must come in, something of similar size goes out.
• Ask "what would we learn?" If a feature would not change what you learn from the first 50 users, it can wait.

A fixed-fee build against a written scope also helps, because every change is visible. See fixed-fee vs hourly development.

When four weeks is the wrong target

Some products cannot honestly be scoped to four weeks, and forcing them into it creates risk:

• Regulated products with compliance work, such as medical records or lending.
• Hardware integrations or complex real-time systems.
• Marketplaces where trust and safety are core to the promise from day one.

In those cases, a staged plan is better: a narrow pilot for a single customer segment first, then expansion. And if the idea still needs validation, spending nothing on development for a few more weeks is the right answer.

How Ottomind can help

Ottomind is an AI lab and software studio. We build and run our own products, including Quborly (hackathons, startup competitions and conferences) and BookOS (AI bookkeeping), and we build products for clients through Ottomind Studio. Scoping is where every studio project starts. Each project gets a fixed price after the scoping call, with UX/UI design included: focused MVPs start from $25,000, startup products from $50,000 and advanced platforms from $85,000. We target a focused v1 in production within about 4 weeks of scope sign-off, with a 30-day warranty. You own your GitHub, cloud, domain and app-store accounts from day one.

The Studio intake gives you an AI-assisted stack recommendation and estimate in minutes, which is a useful way to see whether your current feature list is a 4-week build or needs cutting. If it needs cutting, we will work through it with you before anything is signed.