What an MVP should include, and what can wait

Summary: An MVP should include only what a real customer needs to complete the core job and pay for it: accounts, the main workflow, payments if you charge, basic admin and analytics. Everything else goes on a roadmap.

Define the core job

An MVP exists to prove that customers will use and pay for the core job your product does. Write that job down in one sentence before you list a single feature.

The must-haves

Accounts, the core workflow, payments if you charge, basic admin and analytics. Together these let real customers use the product and let you learn from what they do.

What can wait

Advanced roles, custom reporting, integrations beyond the first one or two, and native apps can usually follow once you have usage data to justify them.

Plan the second release now

Agree what success looks like after launch, and keep a short list of features ready to build when the data supports them. It keeps momentum after launch day.

A one-page MVP scope

Before talking to developers, write a single page that answers these questions. It will save weeks of back-and-forth and make quotes comparable.

The core job, in one sentence.
Who the first users are, and how many.
The three to five screens a user must pass through to get the job done.
How you will charge, if at all, in the first release.
What you will measure to decide whether it worked.
What is explicitly out of scope for release one.

Build versus no-code

If the core job can be delivered with a form tool, a spreadsheet and a payment link, start there. Custom software earns its place when the workflow is the product, when no-code tools cannot handle your data or permissions, or when you need to own the code for investors or scale.

Common scope traps

Most MVPs grow because of a few predictable additions: a native app on top of the web app, complex roles and permissions before there are teams to use them, custom reporting, and integrations with every tool a prospect mentions. Each is reasonable later; few are needed to prove the idea.

Key takeaways

Write the core job down in one sentence first.
Include only what a paying customer needs to finish that job.
Decide in advance what success looks like after launch.
Keep a short, prioritised list for release two.

Questions, answered

How long should an MVP take to build?

Most focused MVPs take ten to sixteen weeks from discovery to launch. Longer than that usually means the scope has grown beyond the core job.

Should the MVP be a mobile app?

Usually not. A responsive web app reaches everyone, is quicker to change, and can become a store app once usage justifies it.

Will we have to rebuild it later?

Not if it is built on a mainstream stack with sensible architecture. An MVP should be the first version of the product, not a throwaway prototype.