How to Scope an MVP Before Design and Development

Originally published on Medium.

Why discovery comes before design and code

Most MVPs fail not because teams move too slowly - but because they start building before the problem is clear.

Discovery-first MVP scoping means answering foundation questions, defining one anchor user story, documenting scope with explicit cuts, and wireframing flows before UI polish or engineering sprints.

This article is for founders and product leaders at the idea or pre-build stage - especially in complex domains where rework is costly. I use MedNote, a personal health records app I took from idea to production, as the worked example. The sequence applies equally to B2B SaaS, enterprise tools, and regulated products.

When this applies: Pre-seed or seed founders, teams hiring first developers, products with fragmented problem spaces, any MVP where stakeholders disagree on v1 scope.

When it does not: Teams with a validated problem, existing users, and clear v1 metrics - move to iterative delivery, not greenfield discovery.

Step 1: Five foundation questions (before any screen)

Before we jumped into design or development on MedNote, I spent three weeks thinking, writing, and questioning everything about the idea.

Here are the five key questions that shaped the foundation - questions I use in product discovery engagements regardless of industry:

1. What problem are we solving?
If there is no clear problem, there is no point in building. In our case, it was chaos around medical information: test results here, doctor notes there, reminders lost in messages. People do their best to stay healthy, but the system is fragmented. MedNote’s mission became simple: bring order to the medical mess.

2. Are there similar solutions out there?
Yes - and that is a good thing. People could use OneNote, Evernote, or a phone notepad, but those tools were not built for healthcare organization. Their UX does not match the needs of people managing personal medical histories. That gap became our opportunity.

3. Can it scale?
I am not excited by static, single-function apps. I explored growth paths: feature expansion, B2B integrations, building a community. The project needed room to grow.

4. Does it reflect me?
I did not want to build an app just to sell it. I wanted something I could improve over time - like restoring a classic car. If I could not see myself doing that, I would stop.

5. Is there a higher mission behind it?
Ours: Prevention is the key to a healthier life. Most health issues can be avoided through regular checkups and awareness. MedNote’s long-term vision is to make that easier, more accessible, and even inspiring.

Before design, before code - comes clarity. That is what those three weeks were about.

Step 2: One anchor user story (and honest decomposition)

After working through the idea, the direction was clear and the problem well defined. We moved to writing initial user stories.

The very first one was simple:

As a user, I want all my health documents to be stored in a single place.

If you are building an MVP, one well-defined user story might be the best place to start. It brings clarity and focus - everything at this stage.

We broke it down into sub-stories:

• As a user, I want to take and add pictures to records I already made
• As a user, I want to group my records to track health issues
• As a user, I want to add media to records I already created
• As a user, I want categories (Appointment, Investigation, Treatment, Note) to navigate my data

Expansion is the enemy of MVPs. We kept it simple, clear, and essential.

Step 3: Minimum documentation - your future self will thank you

Once the idea and user stories were defined, I needed solid documentation - for the team and for future me. Confluence for docs; Jira for tasks.

The first doc was Project Scope - two short paragraphs on the core problem and how the app solves it.

User stories

These formed the backbone. They evolved toward:

• Quick search, linked records, scanning, fast entry
• Tags and notes, chronological view, custom categories
• Security, reminders

List everything, tag each as Must Have or Nice to Have, cut the nice-to-haves. Focus on value with minimal effort.

Functional requirements

MedNote’s list included:

• Google/Apple login
• Create, edit, delete records
• Group into cases, categorize and filter
• Media upload

Even a rough list gives clarity, helps estimate time and cost, and avoids misalignment.

Roadmap

A visual roadmap grounded the sequence:

• Documentation - 2 weeks
• Naming - before design ends
• Design ready - before dev
• Hire dev - after docs and design
• Development - 4–5 weeks
• Landing page - while development

Some tasks had dates, others did not. The point was to start.

Step 4: Wireframes before UI polish

The most logical next step was to visually support every user story.

If you document user stories, follow each with a basic screen structure. That turns abstract ideas into something real and saves time in design, onboarding, and development.

You do not need to overthink tools. I started with Lucidchart, then Figma.

Example: As a user, I want to add a record means:

1. A dashboard or main screen
2. A new record screen with input fields
3. A button connecting the two

Repeat for each story. Wireframes are not design - keep them functional, monochrome, simple. Prototype on your phone; you will find what you forgot: settings, onboarding, password recovery, legal screens.

Rule: Only build what is required to get the user from point A to point B. No more. Not yet.

Step 5: Lean UI - just enough to ship

We did not aim for beauty, branding, or wow-effect. We focused on what was needed to move forward.

Core screens first, plus a small UI kit:

• Two button styles
• A basic input component
• Simple text hierarchy (titles, body, captions)

That minimum let developers assemble decent-looking screens without waiting on every design update.

We left full branding for later but wanted the app to feel clean at MVP stage. We initially chose blue; on the second pass, green tones clicked - subtle, soft, calm.

What product leaders should decide before hiring dev

MedNote is a concrete example of product discovery done before build: problem clarity, one anchor story, ruthless scope, documentation that outlives the first sprint.

If you are scoping an MVP in a complex domain, the sequence matters more than the toolchain:

1. Foundation questions - problem, competition, scale, fit, mission
2. One anchor user story - decomposed with Must Have / Nice to Have
3. Scope documentation - before tickets multiply
4. Wireframes per story - before high-fidelity UI
5. Minimal UI kit - enough for dev to move without blocking

See the MedNote case study for delivery outcomes. For how this connects to product-market fit signals or assessment vs audit, read the related articles.

If you are at the idea stage and need scope clarity before design or code, discuss a similar challenge.