Guide

What to Cut From an MVP to Launch in Weeks

By Fahad Tariq, founder of Zirah Tech · Published November 3, 2026

A long feature list is what makes an MVP late. Most of what founders write down on day one can wait, and a few things on that list cannot.

Start with one core flow, not a feature list

Deciding what to cut from an MVP starts with what the MVP must prove. Write it as one sentence: "A [type of user] can [do one thing] and get [one result]."

Atlassian says an MVP should address customer pain points, give you a way to gather customer insight, and be limited to only a few features. Ralabs, an MVP agency, says MVPs typically have 1 to 3 core features. Atlassian's examples show how small the first version can be: Uber began as an SMS service for calling a cab, and Spotify began as a landing page used to test streaming technology.

If you cannot describe the first useful moment in one sentence, you are still deciding what the product is. Settle that before you cut anything.

Cut these seven things first

This list is a working judgment. Items 1, 2, 3, 5 and 6 rest on agency sources named below; items 4 and 7 are editorial.

1. A native app on both iOS and Android. Asper Brothers lists supporting both at once, instead of launching with a responsive web app, as a common way to double a timeline. Start with the web.
2. A custom-built login system. Asper Brothers names custom authentication, rather than Firebase or Auth0, as a common mistake. You still need login (see below). You just do not need to write it.
3. Heavy infrastructure. Asper Brothers gives the example of AWS plus Kubernetes for a prototype that could live on Firebase. Pick the smallest setup that works. You can move later.
4. An admin dashboard. In the first weeks you can edit records in the database or a spreadsheet. Build the back office once you know what you actually edit.
5. Notifications, dark mode and Slack integrations. Asper Brothers uses these as examples of small additions that turn a 5-week MVP into a 12-week build.
6. Roles, permissions and teams. Start with one kind of user. mvp-development.io says a second user type roughly doubles the flows to build and test. Add roles when a paying customer asks.
7. Settings, profiles and personalization. People trying your core flow do not need to customize it.

A founder on r/startups put it in one line: custom admin dashboards and complex authentication systems can wait, and the focus belongs on core functionality.

Do not cut these four things

"Cut everything" goes too far. Two sources that rank for this topic agree on a short keep list.

• Basic security. mvp-development.io says safe authentication, encrypted secrets and backups are far harder to add once real data is in the system. Selleo lists authentication and secure data storage as part of the trust layer an MVP needs.
• Testing of the core flow. Both sources say a broken first session costs you the feedback you built the MVP to get. Selleo calls QA the smallest investment that keeps the first release stable enough for feedback to mean something.
• Analytics for activation and retention. mvp-development.io says these events must exist on launch day, or the launch produces no evidence.
• Conversations with real users. The same source calls customer interviews during discovery the cheapest way to avoid building the wrong thing, and says to keep them even on a 30-day plan.

Each of these takes days, not weeks, according to mvp-development.io. Cut features instead.

Test every feature with one question

For each feature ask: can a user finish the core flow without it?

• If no, it stays.
• If yes, it is cut or postponed.

This is a short form of MoSCoW prioritization (Must have, Should have, Could have, Won't have this time). For an MVP, only the Must-haves ship. Selleo adds a second check it calls the Two-Test Rule: a feature stays only if it delivers core value or tests the biggest uncertainty about your business.

Why this is worth the argument with your co-founder: a commenter on r/Solopreneur noted that if an MVP has too many features and fails, you will not know which feature caused the failure. A small MVP gives you a result you can read.

Scope sets the weeks, so read the timeline table

Sources disagree on "how long", and the reason is scope. Asper Brothers says 4 to 10 weeks is realistic for most MVPs. Google's AI Overview, citing 7L International, says 8 to 16 weeks for a standard, well-scoped MVP. InApps says standard SaaS MVPs take 10 to 16 weeks and that most founders underestimate by two to three times.

The most useful breakdown comes from mvp-development.io, an MVP agency. These are its typical totals from discovery through launch, for a small experienced team:

Read the "what drives the time" column as your cut list. Removing payments, a second user type or a second platform moves you up the table faster than working longer hours. Treat these as one agency's planning figures, not guarantees. Zirah Tech does not publish fixed timelines, because they depend on what is in scope.

Mobile adds a wait you do not control. Apple says its App Review team typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, and that over 40% of unresolved issues relate to app completeness: crashes, placeholder content and incomplete information. A rejection restarts the clock. A responsive web app skips this step.

Park what you cut on a "Not Now" list

Cutting hurts less when nothing is lost. Asper Brothers recommends a "Not Now" list for every feature that misses the cut, revisited after launch with user feedback. mvp-development.io adds a rule worth copying: accept a new item only by removing something of equal size.

Keep it simple:

• One shared document, one line per idea.
• A note on who asked and why.
• After launch, count how many real users ask for the same thing. Build what repeats.

Lock the scope in writing before the build starts

A cut list only works if it is written down. Use this checklist before any code:

• [ ] One sentence for the core flow
• [ ] A Must-have list of 3 to 7 items
• [ ] A Won't-have-yet list that everyone has agreed to
• [ ] One success measure (for example, "10 people complete the core flow")
• [ ] One person who can approve scope questions, with an agreed turnaround
• [ ] A fixed launch date, even an internal one
• [ ] A rule: new ideas go on the Not Now list, not into the build

At Zirah Tech this is what the scoping step produces: a written proposal with milestones, a timeline and a fixed price or retainer, then short build iterations with regular demos and code in your repo from day one. If you want a second opinion on your cut list, the intro call is free and takes 30 minutes.

FAQ

What should I cut first from an MVP? Anything a user does not need to finish the core flow: a second mobile platform, a custom-built login, admin tools, roles, notifications, integrations and settings. Apply the one-question test to each item.

How many features should an MVP have? There is no fixed number. Atlassian says an MVP should be limited to only a few features, and Ralabs says typically 1 to 3 core features. If a user can finish the core flow, you have enough.

How long does it take to build an MVP? Sources range from 4 to 10 weeks (Asper Brothers) to 8 to 16 weeks or more (other sources above). By one agency's table, a single-flow web app takes 4 to 5 weeks and a native two-platform app 11 to 16. Scope and decision speed explain the gap.

What features should an MVP not have? The seven items above are a good start. Remember the exceptions: keep basic security, core-flow testing and launch-day analytics.

Can I build an MVP with no-code tools? Often, to validate demand. Asper Brothers suggests no-code for landing pages, waitlists, dashboards, directories and simple marketplaces, then rebuilding only if the idea gains traction. Selleo says custom code fits better when performance, scalability, IP ownership or vendor lock-in is the main constraint. Zirah Tech can advise which route fits your case.

What is the difference between an MVP and a prototype or proof of concept? Atlassian describes an MVP as a simple, functional version released to real users to validate demand, while a proof of concept tests whether an idea or technology is feasible and is usually internal.

Why do startups fail even after building an MVP? CB Insights analyzed 431 VC-backed startups that shut down since 2023 and found poor product-market fit cited in 43% of cases with an identifiable cause (the analysis counts 385 companies, and companies could cite several reasons). That is a funded-startup sample, not a study of MVPs, but it shows why learning from real users early matters.