Wall & Fifth
Start a conversation

Home/MVP Development/Features to Include

Features to Include

The skill is not picking features.
It is knowing what to leave out.

Every founder's feature list is too long. An MVP needs the smallest set that proves the core idea, plus the invisible essentials users assume, and nothing else. Here is the framework for deciding what is in, what is faked, and what waits.

Book a scoping call →

The framework

How to decide
what makes the cut.

Start with the one core job

Name the single thing the product must do to prove the idea. Every candidate feature is then judged against it: does this directly serve the core job, or does it merely feel important. Most fail that test, and that is the point.

Keep the invisible essentials

Some features earn no praise but cannot be skipped: authentication, security, basic error handling, a way to recover an account. Users assume these exist and lose all trust when they do not. They are non-negotiable even in an MVP.

Fake what you can

Not every feature needs to be built to be tested. Matching, moderation, or recommendations can often be done manually behind the scenes for the first users. If you can fake it to learn, do, and build it for real only once demand is proven.

Defer the nice-to-haves

Settings pages, profile customisation, secondary flows, and edge-case handling almost always wait. They feel necessary and rarely are, at the stage where you are still proving anyone wants the core thing at all.

Cut anything serving a future you

Features for the scaled, funded, hundred-customer version are for that version. Building them now is spending on a future that the MVP exists to find out whether you will even have. Build for the test in front of you.

Product image placeholder

Sorting your list

Four buckets
for every feature.

Core - build it

Directly proves the central idea. This small set is the actual MVP. If removing it means you cannot test the assumption, it stays.

Essential but invisible - build it

Auth, security, account recovery. No glory, but their absence breaks trust instantly. Build them quietly and properly.

Fakeable - fake it

Can be done by hand for early users to learn cheaply. Automate later, only once the manual version proves the need.

Nice-to-have - defer it

Feels important, is not yet. Write it down, schedule it for after validation, and leave it out of the build.

Future-you - cut it

Belongs to the scaled product. Building it now bets on a future the MVP has not yet earned. Remove it entirely.

Doing it with us

Much of the value
is in the cutting.

MVP Build

From 16,000 GBP

Part of what you pay for is the framework applied to your list: separating core from noise, faking what can be faked, and deferring the rest, so the eight-week build tests the right thing. Owned code, fixed price.

Discovery sprint

Lower fixed cost

If your feature list is still long and unsorted, a short paid sprint to run exactly this framework and produce a scoped, cut-down build plan. Folds into the build if you proceed.

Common questions

Before you get in touch.

How do I decide what features go in an MVP?

Start from the single job the product must do, then judge every feature against it: does it serve the core job or just feel important. Build the small set that proves the idea, keep the invisible essentials users assume, and cut or defer the rest.

What features must every MVP have?

The invisible essentials: authentication, basic security, error handling, and account recovery. They earn no praise but their absence destroys trust instantly. Beyond those, only the features that directly prove the core idea belong in the first build.

What does it mean to fake a feature?

Delivering the outcome manually behind the scenes instead of building automation. Matching, moderation, or recommendations can often be done by hand for early users, so you learn whether the feature matters before paying to build it for real.

What is the biggest feature mistake?

Including too much, especially features built for a scaled, funded future the MVP exists to test whether you will have. Every extra feature delays the lesson and raises the cost of being wrong. The hard, valuable skill is leaving things out.

Should an MVP have a settings or profile page?

Usually not in the first build. Settings, profile customisation, and secondary flows feel necessary and rarely are while you are still proving the core idea. They are classic defer-it features: noted, scheduled, and left out for now.

Can you help me decide what to include?

Yes. Applying this framework to your specific list is part of the build, and a discovery sprint exists for exactly this: separating core from noise and producing a scoped plan before any code is written.

Build the right small thing.

Book a scoping call →