How to Plan an MVP Before Hiring a Developer

Start With the Hypothesis, Not the Feature List

Before listing features, write down the one thing you're actually trying to learn from real users. "Will people pay for this?" and "will people use this daily?" lead to different MVPs. Every feature decision should trace back to that question.

Separate "Needed to Validate" From "Nice to Have"

List every feature you imagine the finished product having, then mark each one: does this need to exist for the core hypothesis to be testable, or is it something you're adding because it feels incomplete without it? Most first-draft feature lists are 60–80% the second category.

Define What Success Looks Like Before You Launch

Decide the metric or signal that tells you the hypothesis was right — a conversion rate, a retention number, qualitative feedback from a set number of users — before development starts. Deciding this after launch means you're rationalising a result instead of testing a hypothesis.

Know Your Non-Negotiables

Some things aren't optional even in an MVP — data security, basic reliability, App Store compliance. Separate "minimum viable" from "cutting corners that create real risk or rework later."

What to Bring to a Scoping Conversation

• The core hypothesis you're testing
• A rough feature list, marked "essential" vs "later"
• Who the first users are and how you'll reach them
• Any hard constraints — budget ceiling, launch deadline, existing systems it needs to work with

You don't need a finished spec — a developer worth working with will help you turn this into one. But arriving with these answered makes that conversation dramatically more useful than "I want to build an app like X."