SELF-CHECK · MVP SCOPE
MVP scope planner
The MVP scope planner helps you decide what to build first. It sorts the features you think you need into Build first, Later and Cut, with a range of weeks and cost.
The drawing shows a first version planned on a week ruler and, under it, the work that reaches first users, with later features parked and cut ones struck out.
Build first is what your first users need to get the core job done. Later can wait until they ask for it, and Cut is for extras that need evidence from real users first. You get a range of weeks and an MVP development cost range from a weekly team cost you set, so you can cut scope before it costs you. Every assumption is shown.
Your first build
Start with setup and your core workflow: about 3 to 6 weeks for a senior team.
Pick the features you think you need to see where each one belongs.
Estimate First build: about 3 to 6 weeks for a senior team. At $8,000 a week (the example weekly cost), that is about $24,000 to $48,000.
Build first 2
- Setup: code repository, hosting, deploys, backups and error logging always included, 1 to 1.5 weeks
- Your core workflow: the one job your product does always included, 2 to 4 weeks
Later 0
Nothing to move later.
Cut 0
Nothing to cut.
Where each feature belongs, and why
- Sign-up and sign-in: build first, 1 to 1.5 weeks. Most products need to know who the user is in order to save their work.
- A short first-run guide: build first, 0.5 to 1 week. New users who never reach the core workflow tell you nothing about it.
- Product analytics on the core workflow: build first, 0.5 to 1 week. Without usage data you cannot tell whether the first version worked.
- Account emails: welcome, password reset and receipts: build first, 0.5 to 1 week. Users expect them, and missing ones turn into support requests.
- Subscriptions and billing: later, 1.5 to 3 weeks. Early customers can pay by invoice or a hosted payment link while you learn what to charge.
- An admin dashboard: later, 1 to 2 weeks. Your database console and a spreadsheet export cover the first months.
- Team accounts and roles: later, 1.5 to 3 weeks. Add it when a paying customer needs to invite colleagues.
- Search and filters: later, 1 to 2 weeks. Search matters once users have more data than fits on one screen.
- Integrations with other tools: later, 1 to 3 weeks. Build the one integration customers ask for most, once they ask for it.
- File uploads and storage: later, 0.5 to 1.5 weeks. Unless files are the core workflow, start with links or email attachments.
- Reports and exports: later, 1 to 2 weeks. A spreadsheet export answers most early reporting questions.
- A public API for developers: later, 2 to 4 weeks. Wait until customers ask to connect their own systems.
- Native iOS and Android apps: cut, 6 to 12 weeks. A responsive web app works on phones and skips app store reviews while you test the idea.
- An AI assistant or chatbot: cut, 2 to 4 weeks. Unless AI is the core workflow, add it after you see what users actually ask for.
- Several languages: cut, 1 to 2 weeks. Translate once there is demand outside your first market.
- Dark mode and custom themes: cut, 0.5 to 1 week. Nice to have, and every screen needs a second theme to check.
- Comments, feeds and other social features: cut, 2 to 4 weeks. Social features need many active users before they work.
- Offline mode: cut, 2 to 4 weeks. Offline sync is hard to get right, and few first versions need it.
- The weeks assume two senior people working full time: one engineer, and one product and design lead.
- The ranges are planning estimates, not quotes. Real timelines depend on your data, your integrations and how quickly decisions get made.
- Setup and your core workflow are always part of the first build.
- Weeks are rounded up to whole weeks. The cost range is the week range multiplied by the weekly cost you enter.
- Features you move later still take time when you build them. The planner only takes them out of the first release.
Your Build first lane is your first MVP scope. Bring it to a 20-minute call and we will pressure-test it with you.
Book a 20-minute call (opens Google Calendar in a new tab)STEP BY STEP
How the MVP scope planner works
- Pick every feature you think the first version needs, from sign-in to payments to admin tools.
- The planner places each one in a lane and shows the reason as soon as you tick it. Build first is what your first users need to get the core job done. Later is what can wait until users ask for it. Cut is what adds time without testing the idea, such as native mobile apps or several languages.
- You get a range of weeks and an MVP development cost range for the first build, with the assumptions behind both. A week ruler shows what each pick adds and when a first version could reach users.
Splitting your list into lanes shows what each extra feature adds in time and money before anyone has used the product. That is MVP feature prioritization in its simplest form: build the smallest thing that tests your riskiest assumption, then let real usage decide the rest.
Your choices stay in your browser. Nothing is sent to BrainStormers or stored. If website analytics is on, the page counts one event when a plan is shown, without your choices.
METHOD
Where the ranges come from
Roger Grekos (Co-Founder, Product, Project & Scale) wrote the planner and its feature list. Thanos Gkanas (Co-Founder & Head of Engineering) checked its week ranges.
Each feature carries a low and a high estimate in weeks, because a single number would hide how much a feature can grow once the details appear. The cost range is those weeks times the weekly team cost in the form. That cost starts as an example input: two people at $100 an hour for 40 hours a week. It is not a BrainStormers price or a market rate, so change it to match your quote.
Treat the result as a planning range, not a quote. Real timelines depend on design, integrations, review cycles and how quickly decisions get made. For worked minimum viable product examples, our guide walks through the MVP development process step by step. If you have not tested demand yet, the market validation process comes before any of this. When the scope feels right, we can turn it into a build plan and a working product through MVP development for startups.
Checked · Checked by Thanos Gkanas
FAQ
Questions about MVP scope
What belongs in an MVP scope?
Only what your first users need to complete the core job your product promises, plus what you need to learn from them. That usually means one main workflow, sign-in, the data that workflow depends on and a way to measure use. Settings, admin dashboards, integrations and edge cases can usually wait for the second release.
How does the planner estimate MVP development cost?
It adds up the week ranges of setup, your core workflow and the features you build first, then multiplies them by the weekly team cost in the form. That cost is an example input, so change it to match your quote. You get a low and a high figure, because details found during a build move the cost.
How accurate is the week range?
It is a planning range, good enough to compare scopes and to spot an MVP that is too big, but it is not a quote. Each feature has a low and a high estimate, and real timelines also depend on design, integrations, review cycles and how fast decisions get made. Plan around the high end.
Which features do founders most often cut from an MVP?
The ones that serve the business before the user. Admin dashboards, detailed settings, multiple user roles, native mobile apps, complex billing plans and integrations nobody has asked for yet are common cuts. Each one can be added later, once real users show you they need it and how they would use it.
Can I share my plan with a co-founder or developer?
Yes. Your plan stays in your browser, so the planner keeps no copy and needs no account. To share it, print the page or save it as a PDF from your browser's print menu. You can also copy the three lanes, Build first, Later and Cut, into the document your team already uses.
NEXT STEP
Test the scope before you build
A good MVP scope is a bet on one assumption. Tell us what you are building and who it is for, and we will help you find the smallest version worth shipping.