What to Build First: An MVP Guide for Founders
The expensive mistake is not building the wrong feature — it is building thirty features before finding out which two people use. A practical way to cut scope.
Almost every first-time founder we work with arrives with a feature list, and almost every one of those lists is too long. Not because the ideas are bad, but because they were all thought of at the same time, before a single real user had touched anything.
The costly mistake is not picking the wrong feature. It is spending the entire budget on thirty features, launching, and only then discovering that customers use two of them. At that point there is no money left to build on what you just learned.
An MVP is the fix, and it is widely misunderstood. It does not mean a cheap or unfinished product. It means the smallest thing that lets a real customer complete the one action your business depends on.
Start from the one action, not the feature list
Every business has one action that has to work for money to move. For a delivery business it is placing an order. For a clinic it is booking a slot. For a marketplace it is a buyer contacting a seller.
Write that one action down in a single sentence. Everything that is not required for someone to complete it, from start to finish, is not in version one. Not deleted — just not now.
This is a harder exercise than it sounds, because most of the features you want to cut are genuinely good ideas. They will still be good ideas in three months, with the advantage that by then you will know which ones users are actually asking for.
What almost always gets cut from version one
- Admin dashboards with charts — early on you can read the database or a spreadsheet
- User profiles, avatars, settings screens
- In-app chat, when WhatsApp already works and is where your users already are
- Multiple user roles, when there are three users
- Notification preference screens — send the one notification that matters
- Anything justified with "we will need it when we scale"
That last one deserves emphasis. Building for scale you do not have yet is the most expensive form of optimism in software. Scale problems are real, but they are problems you get to have after people show up.
What you should not cut
- The one core action working properly, end to end, without workarounds
- Working on a cheap Android phone on a weak connection
- A way to contact you when something breaks
- Basic analytics, so you can see what people actually do rather than guessing
- Login security done correctly, if there are accounts at all
Analytics is the one founders skip most often, and it defeats the whole purpose. The point of shipping small is to learn — and without instrumentation you launch, get some usage, and still have only opinions about what happened.
Wireframes before code, always
Ask for screen-by-screen layouts before anyone writes code. Changing a wireframe costs nothing. Changing built software costs money and time, and changing built software after launch costs more again.
Wireframes also expose scope you did not know you had asked for. A founder looks at nine screens and says "wait, do we need this one?" — and that conversation, held at the wireframe stage, is where budgets actually get saved.
Web first, app later, in most cases
For a first version, a web app is usually the better bet even if the eventual product is a mobile app. You can send someone a link and they are using it in two seconds. Getting a stranger to install an app is a much harder ask, and it sits between you and every early user you are trying to learn from.
Once people are returning regularly, an app becomes worth building — and by then you know exactly which screens they use, so you build the right app rather than a guess.
Sensible expectations on time and money
A web MVP with one core flow is usually 4 to 8 weeks. A mobile MVP takes longer because of store submission and device testing. A full product with payments, roles and an admin dashboard runs 3 to 5 months.
Insist on a fixed written price for a defined scope. Hourly billing on an open-ended scope is how new founders lose control of a budget, because there is no point at which anyone has to say "that is extra".
And make sure everything is registered in your name: domain, hosting, Play Store, App Store, with the source code handed over. If your developer relationship ends, badly or amicably, you should be able to walk away with the whole thing.
After launch, the actual work starts
Launch is the point where you start learning, not the finish line. Watch where people drop off. Talk to the ones who stopped using it — they will tell you more than the ones who love it.
Then build the next thing based on what you saw, not on the feature list you wrote before anyone had used anything. That list was a set of guesses. You now have data, which is a much better thing to spend money on.
Want this done for your business?
We are a website and app development team in Balaghat, Madhya Pradesh, working with clients across India. Free consultation, fixed written quote, open all seven days.
All articles