We're sent a lot of MVP specifications. Most describe seven months of work.
That's not an MVP. It's a product, built with a startup's budget and a startup's runway, and it fails in a predictable way: the money runs out before anyone finds out whether the core idea was any good.
The bloat is never one bad decision. It's twenty reasonable ones. A co-founder adds a feature. An advisor mentions a competitor has something. Somebody says "while we're in there, we should also…" Each addition costs a few days and sounds sensible. Together they turn seven weeks into seven months.
Here's how to cut it back.
The question that decides everything
Before any feature discussion: what do you not yet know, that this build will tell you?
Every startup rests on an assumption that might be wrong. Usually one of:
- People have this problem badly enough to change what they currently do
- They'll pay to solve it
- We can reach them affordably
- We can actually deliver the thing at a workable cost
Your MVP exists to test the riskiest one. That's it. Every feature either contributes to that test or is a bet you're making before you needed to.
This reframing does most of the cutting on its own. "Should we build user profiles?" is unanswerable in the abstract and easy once you ask whether profiles are needed to learn whether people will pay.
And note: if your riskiest assumption is "will anyone want this," the fastest test may not be software at all. A landing page, ten sales conversations, or a manual service run over WhatsApp can answer it in two weeks. Building software to test demand is often the slowest available method.
The test for every feature
For each item on the list: what happens if we launch without it?
Three honest answers:
"We can't launch." It's genuinely core. Keep it. This list is much shorter than people expect — usually three to five things.
"Some users will be annoyed." Cut it. Annoyance is survivable and informative. You'll learn which annoyances people tolerate, which tells you what to build next based on evidence rather than guessing.
"We'd have to do it manually." Cut it, and do it manually. This is the most valuable category and the most consistently overlooked. See below.
Anything failing to produce a clear "we can't launch" goes to a list called Later. Not Never — Later. That distinction matters politically, because it's how you cut a stakeholder's feature without a fight.
Do it manually first
The strongest scope-cutting move available, and the one founders resist most.
If your product needs to match buyers with sellers, you don't need a matching algorithm to start. You need a spreadsheet and someone doing the matching by hand. If it needs to generate a report, someone can write the first fifty in a document.
Users don't care whether a human or a system produced the result. They care that they got it.
What this buys you:
- You launch in weeks instead of months.
- You learn what the rules actually are. You cannot write good matching logic before you've done matching by hand. Teams that automate first build the wrong algorithm and then rebuild it.
- You find out whether anyone wants it before spending three months on the engine.
- Your first users get better service, because a human handles edge cases a v1 system never would.
The obvious objection is that it doesn't scale. Correct — and irrelevant. If you get to the point where manual is unsustainable, you have demand, which is the thing you were trying to learn. That's a good problem, and now you know exactly what to automate because you've been doing it.
The rule of thumb: automate a process after you've run it manually enough times to be bored by it. Boredom means you understand the rules.
What almost never belongs in v1
Consistent across the specs we see:
An admin panel. Weeks of work to rebuild a worse version of a database client. Use a SQL client, or point a tool like Metabase at your database. Build the admin panel when non-technical staff need it daily.
Settings and preferences. Every setting is a branch to build, test and support. Pick sensible defaults. Add a setting when users actually complain, which is much rarer than expected.
Onboarding flows and tutorials. Elaborate walkthroughs for a product whose shape will change within a month. Your first users need a conversation, not a product tour — and that conversation teaches you more than any analytics on tutorial completion.
Multiple user roles and granular permissions. If your first customers are small teams where everyone trusts everyone, one role is fine. (Keep the authorisation layer in place from day one — that's an architectural decision — but you need exactly one role in it.)
Notification systems. Email digests, in-app notifications, preference centres. Send one transactional email. Add more when someone asks.
A mobile app, when a web app would do. This one costs the most. A responsive web app means one codebase, no store review, and instant updates. Build native when you need something only an app provides — push notifications as a core mechanic, offline use, camera or hardware access. "Users expect an app" is not that reason, and it can double your build.
Multi-language support. Real work touching every screen. Launch in one language. Add languages when you have users asking in another.
Search, when a filter would do. Proper search is genuinely hard. With 200 items, a dropdown filter works fine.
Analytics dashboards for users. Charts of their own data. Almost nobody looks at them in month one. Ask instead of assuming.
Anything for scale you don't have. Caching layers, queues, horizontal scaling. Your first hundred users fit comfortably on one modest server.
What people wrongly cut
Cutting scope is not cutting quality. These get skipped and cost far more than they save:
Authentication done properly. Rolling your own auth to save time is a false economy. Use a proven library or service. A security incident with your first ten customers is not survivable.
Payment correctness. If you take money, take it correctly — server-side verification, idempotent webhooks, real reconciliation. The failure mode here is charging someone twice, and that's your reputation.
Error handling and a way to see failures. Ship with error tracking from day one. Without it you're relying on users to report problems, and most won't — they'll just leave.
Basic analytics. You need to know what people actually do. Not a dashboard — just event tracking on the handful of actions that matter. Without this you learn nothing from launching, which defeats the purpose.
Data you can't recreate. Take backups. Losing early customer data is unrecoverable in a way that a missing feature never is.
The pattern: cut features, keep foundations. Foundations are cheap now and expensive later. Features are cheap whenever you build them.
A test for whether you've cut enough
Can you describe it in one sentence without "and"?
"Restaurants list surplus food and customers buy it at a discount" is an MVP. "Restaurants list surplus food, customers buy at a discount, plus a loyalty programme, delivery partner integration, and analytics for restaurant owners" is four products.
Is it six to eight weeks of work? Beyond that, the market moves, the team loses momentum, and you burn runway before learning anything. If your scope is six months, you haven't cut enough — you've made a plan.
Would you be embarrassed to show it? Slightly embarrassed is about right. Deeply embarrassed means you cut a foundation. Not embarrassed at all means you built too much.
The India-specific argument
Two reasons this matters more here.
Runway is the binding constraint. Early-stage funding is tighter and rounds take longer. Three extra months of build is three months of salaries spent before you learn anything — and if the answer turns out to be "nobody wants this," that money bought you nothing.
The talent cost is not actually low. Good senior engineers in Bengaluru or Chennai are not cheap. A four-person team for an extra four months is a serious number. That budget is much better spent on a second attempt informed by real data than on features nobody validated.
The founders who succeed here are usually not the ones who built the most impressive v1. They're the ones who got something real in front of users fastest and still had money left to act on what they learned.
How to actually do the cut
Take your feature list. For each item, write the honest answer to "what happens if we launch without it?"
Then sort into three columns: can't launch / do it manually / later.
If "can't launch" has more than five items, you're being generous with yourself. Do it again, harder. Ask what a competitor with two weeks and no budget would build.
Then commit to a date, not a scope. Pick eight weeks out and ship whatever is genuinely ready. A date forces honest prioritisation in a way a feature list never does — a list always expands to fill the time available.
Want a second opinion on your scope?
We build MVPs for founders in India, and a lot of our value is arguing features out of the first version. If you have a spec and a suspicion it's too big, send it over — we'll tell you what we'd cut and why, whether or not you work with us.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our services · WhatsApp: +91 9677749648