MVP development: what to build first (and what to skip)

The hard part of MVP development is not the building. It is deciding what not to build. A minimum viable product earns its name by doing one job well enough to prove people want it, and leaving everything else for after you have that proof. Founders rarely fail because their first version was too small. They fail because they spent months and most of their cash building features nobody had asked for yet.

TL;DR

An MVP exists to test one bet: that people want the core thing your product does. Build only what tests that bet.

Pick the single job your product must do, ship it end to end, and push roles, dashboards, settings, and polish to later.

Most software features go unused. About 80 percent are rarely or never touched (Pendo, 2019), so building more upfront usually wastes runway.

Skip the MVP only when shipping thin would be unsafe or demand is already proven. Otherwise, smaller and sooner wins.

This guide covers what an MVP is really for, how to choose the one feature that goes first, a cut list for everything that can wait, and the cases where an MVP is the wrong call.

What MVP development is actually for

An MVP is a test, not a shrunken copy of the finished product. The goal is to learn whether the core idea holds, using the least amount of building it takes to find out. That reframe changes every later decision: if a feature does not help you learn whether people want the product, it does not belong in the first release.

The word that trips people up is “viable.” Viable does not mean half-finished. It means a real user can complete a real task and get real value, start to finish. A login page with three broken buttons behind it is not an MVP. One feature that works cleanly is. So the bar is narrow but not low: do one thing, and do it well enough that a stranger would use it and, ideally, pay for it.

Start with the one job your product must prove

Before you list features, write one sentence: my product helps [a specific person] do [a specific job]. Everything in the first build should serve that sentence and nothing else.

For a booking tool, the job might be “let a customer reserve a time without calling.” For a marketplace, “let someone list an item and let someone else find it and make contact.” The MVP is the shortest honest path to letting a real user finish that job. If you cannot say the core job in one line, you are not ready to scope a build yet. You are still ready to talk to customers.

How to decide what makes the first cut

For every feature on your wish list, ask one question: can a user get the core value without this in version one? If the answer is yes, it waits. That single test does more than any framework, though the well-known MoSCoW method (must have, should have, could have, will not have) is a fine way to write the decision down.

The rule sounds obvious and is brutally hard to follow, because every cut feature has a reasonable champion. Settings make power users happy. An admin dashboard feels professional. The discipline is holding the line: a feature that a reasonable person wants is still a cut if the product proves its core bet without it. You are not deleting those ideas. You are sequencing them behind evidence.

What to skip in version one

Most of what feels essential is really a second-release item. Here is the work that can usually wait, and why.

Feature you can usually cut	Why it waits
User roles and permissions	One user type is enough to test the core job; tiers add real engineering for no early learning
Admin dashboards and analytics	You can read your own database by hand at ten users; build reporting once volume demands it
Settings and customization	Pick sensible defaults; preferences matter only after people use the thing daily
Every integration but one	Connect the single system the core job needs; the rest are separate mini-projects each
A native mobile app	A responsive web app reaches everyone and ships faster than two app-store builds
Automated billing	Invoice your first customers manually; you learn more from those conversations anyway
Polished onboarding and edge cases	Walk early users through it yourself; handle the rare cases once you know they happen

Read the table as a sequence, not a list of things you will never do. Each row is a feature you build later, on purpose, once usage tells you it is worth the hours.

Where MVP development burns the most runway

Over-building is the quiet, expensive mistake, because the evidence backs the smaller bet. Pendo’s analysis of anonymized product usage found that about 80 percent of features in the average software product are rarely or never used, and roughly 12 percent of features drive 80 percent of daily usage (Source: Pendo, 2019). Building the full feature list before launch means paying to create things most users will never open.

The stakes show up in the failure data too. In a review of 431 venture-backed companies that shut down, weak product-market fit was a factor in 43 percent of them (Source: CB Insights, 2026). The cheapest insurance against that outcome is to spend as little as possible before you know the market is there. An MVP is that insurance. Build the core, ship it, watch which parts people actually use, then put your later money into the demand you can see rather than the demand you guessed at.

When an MVP is the wrong move

An MVP is the default for a new product, but not a law. A few situations call for raising the floor or skipping the lean first version entirely.

Safety and regulation come first. If a thin release could hurt someone or break a rule, the viable bar is higher by definition. A medical or financial product often needs compliance and security in place from day one, so its smallest responsible version is larger than a typical MVP.

Trust-critical infrastructure is the second case. For a developer tool or a system other products depend on, a flaky first version damages the reputation you need, so “minimum” still has to be solid.

The third is simpler: you already have validated, paying demand and a clear specification. If customers are lined up and the requirements are settled, you may be past the experiment stage, and building the real product is the right call. The rule: if shipping thin would be unsafe or would actively burn trust, raise the floor; otherwise, default to smaller and sooner.

A practical way to scope your first build

Picture a peer-to-peer rental marketplace. The wish list runs long: search filters, ratings, in-app messaging, automated payouts, a mobile app, a dispute system. Run each through the core-value question and the first build shrinks fast. Keep: list an item, browse items, and contact the owner. Cut, for now: filters, ratings, messaging, and automated payments. You can match buyers and sellers by hand and take payment manually for the first dozen deals, and you will learn more from doing it manually than from any dashboard.

That is the whole method. Name the one job, build the shortest path to it, do the unglamorous parts by hand, and let real usage tell you what to build next.

How we help you scope version one

We earn our keep by talking founders out of features, not into them. Before anything gets built we agree on the single thing your first release has to prove, scope it, and write the price down so you approve a figure instead of meeting a surprise later. You can work with us on a fixed scope or month to month, there is no lock-in, and the code, the accounts, and the design files are yours from the start.

You can see how we build custom software for early teams, and for the smaller packaged work our flat prices live on the pricing page. If you are not sure custom code is even the right first step, validate cheaply with no-code first, and when you want to understand the numbers, here is what a custom build costs. Once your product is live and being found matters, our SEO for startups program picks up from there. When you want a real read on your own scope, the fastest route is a call with an engineer.

Frequently asked questions

How many features should an MVP have?

As few as it takes to prove the core bet, which for many products is a single end-to-end flow. The honest count is not a number, it is a test: include a feature only if a user cannot get the core value without it. Everything else is a later release.

How long should MVP development take?

Usually weeks to a few months, depending on the one job you are building. If your timeline runs past a year, the scope is too big for an MVP, and the fix is to cut features rather than add months. A long build before any user feedback is the pattern an MVP exists to avoid.

What is the difference between an MVP and a prototype?

A prototype tests an idea or a design, often without working code, and you usually throw it away. An MVP is a real product that a user can complete a task with and pay for, and you build on top of it. Prototypes answer “does this make sense”; an MVP answers “will people actually use it.”

Should I build my MVP with no-code or custom code?

Use no-code when you are still proving demand and the app is straightforward, since it is faster and cheaper to start. Move to custom code when you hit a limit a builder cannot pass. We compare the two in detail in custom software vs no-code.

How do I know when to stop adding features and launch?

Launch when the one core job works cleanly from start to finish, even if everything around it is rough. The instinct to polish before launch is the instinct to delay learning. If the core flow works and a stranger could use it, ship and start watching.

Is an MVP still worth it if I already have funding?

Yes, often more so. Funding does not remove the risk of building something the market does not want, it raises the cost of finding out late. An MVP lets you spend a slice of the round to confirm demand before you commit the rest to a full build.

Want help deciding what your first version should and should not include? Book a call and walk us through the idea. The first conversation is with an engineer, costs nothing, and ends with a straight answer on what to build first and what can wait.