What to build first: the MVP feature set that actually gets paying users

MVP is the most misused term in software. It has drifted from Eric Ries's original definition — the smallest thing that lets you start learning — into "version one with slightly fewer features than we wanted".

That drift is expensive, because it turns a six-week experiment into a five-month build, and five-month builds are where budgets and momentum die.

The working definition

An MVP is the smallest version that lets a real user do the one core thing your product exists to do, handling real users, real data and ideally real money.

Three implications founders resist:

• It has to actually work. A prototype that demonstrates the idea is not an MVP. Nobody pays for a demonstration.
• One core thing. Not three. If you cannot name it in a sentence, the scope is not finished.
• Ideally real money. Payment is the strongest signal available and it costs almost nothing to add with a managed billing service.

The filter

For every feature anyone proposes, ask: does this validate the core value proposition, or accelerate early traction?

If neither, it does not go in version one. Not "we will decide later" — out, in writing, on a list called "not now" so it stops being discussed.

MoSCoW works well here, and its value is entirely in the fourth column:

Category	Meaning	Goes in MVP?
Must have	The product does not function without it	Yes
Should have	Important, but the product works without it	No
Could have	Adds value, not essential	No
Will not have	Deliberately deferred	No, and say so out loud

Most feature lists come back with everything in "must have". That is the signal that the exercise has not been done properly. If everything is essential, nothing has been prioritised.

What almost every SaaS MVP genuinely needs

1. Sign up and log in. Use a managed service. Do not build authentication.
2. The one core workflow, working end to end with real data.
3. Payment. Stripe. One plan is enough. Do not build billing infrastructure.
4. A basic admin view so you can see what users are doing and fix things manually.
5. Transactional email. Password reset, receipts, key notifications.
6. Something that tells you what people actually do — even basic event tracking.

That is the whole list. Everything else is version two until a paying customer tells you otherwise.

The features founders add that nobody uses

Feature	Why it waits
Multiple pricing tiers	You do not know what people will pay for yet. One plan.
Team accounts and permissions	An architectural decision touching every query. Only when a customer needs it.
An analytics dashboard for users	Almost always the second-most requested and least used feature
Mobile app	Build the web version first. Add mobile when product-market fit is clear.
Public API	Nobody integrates with a product that has no users
Onboarding tours and tooltips	With ten customers, onboard them personally. You will learn more.
Dark mode	It is not the reason anybody will or will not pay
Custom branding for customers	An enterprise feature, at a stage where you have no enterprise customers

The team accounts row deserves emphasis. It looks like a settings screen and it is a data-architecture decision affecting every query in the system. It is one of the most common causes of an MVP budget doubling, and it is very often not needed until customer number twenty.

Do things manually for as long as you can

The most underused cost-control technique in early SaaS: if something can be done by a person for the first twenty customers, do not build it yet.

• Onboarding? Do it on a call. You will learn what confuses people.
• Reports? Send them manually. You will discover what they actually want to see.
• Account setup? Configure it yourself. You will notice which steps are unnecessary.

Every manual process is research you are being paid to conduct. Automate it once you know its final shape, not before.

How to scope this in one afternoon

1. Write the one core thing in a sentence. "A user can [do the thing] and get [the outcome]."
2. List every step required for that sentence to be true, in order.
3. Cross out any step that could be done by a human for the first twenty customers.
4. What remains is your MVP.
5. Put everything else on a "not now" list with a date to review it, so it stops being argued about.

The cost of getting this wrong

Scope is the difference between a $15,000 build and a $60,000 build, and it is decided before any code is written. Feature prioritisation before development starts is the single most effective lever on cost — considerably more effective than negotiating a day rate.

It is also why a paid discovery phase before a build tends to pay for itself. Producing a written scope, a page list and a definition of done converts an estimate into a commitment, and scope disputes are what actually destroy software projects.

When we scope a build, the most useful thing we do is usually telling a founder what not to build. It is a smaller project for us and a considerably better outcome for them — which is the right trade, because the founder whose first version ships in ten weeks and finds paying users is the one who comes back for version two.