How to Prepare an Idea for MVP Development

Most founders walk into their first conversation with a development team carrying an idea in their head and very little on paper. The developer asks a handful of basic questions — who is this for, what does it need to do first, what’s the budget — and the founder is answering for the first time, out loud, on the call. That’s not a great way to start a project that’s about to cost real time and money.

This post is a worksheet, not an essay. It’s the set of fields a founder should fill in — actually type out, in a document or a note — before that first call. If you’ve already done the deeper thinking about your idea, this is where you turn it into something concrete. If you haven’t done that thinking yet, this worksheet will feel harder to fill in than it should, which is itself useful information.

Why a Worksheet, Not Just a Conversation

A first call with a development team works best when it’s a conversation about tradeoffs, not a discovery interview. If the founder shows up with clear, written answers, the call becomes: “Here’s what I know, help me figure out the rest.” If the founder shows up with only a vague idea, the call becomes an improvised Q&A, and important details get glossed over because nobody had time to think about them properly in the moment.

Writing answers down also forces precision. “Small business owners” sounds specific until you try to write one sentence about what they do all day and where they get stuck. A worksheet exposes the gaps in your own thinking before a developer has to point them out for you — and it gives you something to revise, rather than something to remember correctly under pressure.

The Worksheet

Copy these fields into a document and fill them in honestly. Short, plain-language answers are better than polished ones — this is a working document, not a pitch.

Problem and Customer

• In one sentence, the problem is: _______________
• The person who has this problem is: _______________ (be specific — a job title, a situation, a habit, not “everyone”)
• They currently deal with this problem by: _______________ (a workaround, a competitor, doing nothing)
• I know this problem is real because: _______________ (a conversation, a workaround you’ve observed, a pattern you’ve experienced firsthand)

The Core of Version One

• The one thing they must be able to do in v1 is: _______________
• If v1 only did this one thing and nothing else, it would still be worth using because: _______________
• The moment someone gets real value from this product is when they: _______________ (describe the exact action — booked something, got an answer, saved something)

Features

• Must-have features (v1 breaks without these):

  1. ---

  2. ---

  3. ---

• Nice-to-have features (valuable, but can wait):

  1. ---

  2. ---

  3. ---

• Features I’ve been tempted to add but suspect aren’t needed for v1: _______________

Budget and Timeline

• My rough budget range is: _______________ (a real range, not a placeholder — an honest number changes what’s realistic to discuss)
• My timeline hope is: _______________ (when you’d like to have something real in front of users)
• My hard deadline, if I have one, is: _______________ (an investor demo, a seasonal launch window, a personal constraint — and why it’s fixed)

Decisions and People

• The people who need to approve decisions along the way are: _______________ (a co-founder, an investor, yourself alone)
• Who will be the single point of contact with the development team: _______________
• How I’ll know this MVP is working after launch (the metric or signal I’ll watch): _______________

Open Questions

• Things I’m genuinely unsure about and want a developer’s input on: _______________
• Technical risks I suspect exist but can’t evaluate myself: _______________ (an AI feature, a complex integration, a payment flow — anything you’re not confident about)

What a Filled-In Worksheet Looks Like

A useful worksheet doesn’t read like marketing copy. It reads like this:

Field	Weak answer	Useful answer
Problem	“There’s no good app for scheduling”	“Independent tutors juggle bookings across text, email, and a paper calendar, and double-book themselves at least once a month”
Customer	“Anyone who teaches”	“Independent tutors managing 20+ students without an assistant”
Core v1 action	“Manage their business”	“See all upcoming sessions in one calendar and let a student request a new time slot”
Budget	“As cheap as possible”	“$8,000–$15,000 for a first version”
Timeline	“ASAP”	“Something testable with 5 real tutors within 8 weeks”

Notice that the useful answers aren’t longer for the sake of it — they’re specific enough that a developer could act on them without asking a follow-up question first.

Where This Fits Before You Talk to a Developer

This worksheet assumes you’ve already done some thinking about your idea, not that you’re starting from a blank page. If you haven’t worked through the problem, the customer, and your core assumption yet, that thinking exercise comes first — see Startup Concept Development: How to Shape an Idea Before Building for how to get there. This worksheet is the next step: it takes that thinking and turns it into a concrete document you can actually hand to someone.

Once this worksheet is filled in, you’re not quite ready to start coding yet — there’s a more technical layer of preparation still to do: written requirements, wireframes, a tech stack decision, and defined success metrics. That’s covered in From Concept to Working Software: What Needs to Happen Before Coding Starts, which picks up exactly where this worksheet leaves off.

It’s also worth cross-checking your must-have list against a dedicated exercise in feature triage — MVP Feature Prioritization: A Practical Founder’s Guide walks through how to separate what v1 actually needs from what can wait, in more depth than the worksheet above has room for.

And if budget is the field you’re least confident about, How Much Does an MVP Cost? breaks down what actually drives MVP pricing, which can help you turn a vague guess into a defensible range before your first call.

Bringing the Worksheet Into the First Call

Once it’s filled in, don’t treat the worksheet as a finished spec — treat it as a starting position. A good development team will read it, ask clarifying questions, and probably push back on a few of your must-haves. That’s the point of writing it down: disagreements happen on paper and in conversation, where they’re cheap to resolve, instead of mid-build, where they’re expensive.

Bring the worksheet as-is to the first call. Don’t polish it into a formal document first — the raw, honest version is more useful to a developer than a tidy one that hides the parts you’re still unsure about. The open-questions section especially is worth sharing directly; naming what you don’t know is more valuable than pretending you do.

Frequently Asked Questions

What should I prepare before building an MVP?

At minimum, a one-sentence problem statement, a specific description of who has that problem, the single thing your v1 must let them do, a rough budget range, a realistic timeline, and a short list of must-have versus nice-to-have features. Filling in a worksheet with these fields before your first developer call saves both sides a lot of back-and-forth.

What questions should I answer before developing an MVP?

What problem am I solving, for whom, and how do I know it's real? What is the one thing v1 must do well? What can wait until after launch? What is my budget range and timeline? Who needs to approve decisions along the way? Answering these on paper, before a call, makes the first conversation with a development team far more productive.

Do I need a full business plan before contacting an MVP developer?

No. A worksheet covering problem, customer, core feature, budget, timeline, and must-have features is enough to start a meaningful conversation. A full business plan is a separate exercise and isn't required to scope an MVP.

How detailed does my budget range need to be before I talk to a developer?

It doesn't need to be exact, but it should be a real range you're prepared to spend, not a placeholder. A vague or unstated budget makes it hard for a development team to tell you honestly what's achievable, which usually leads to a scope that doesn't match your expectations.

What's the difference between a must-have and a nice-to-have feature in this worksheet?

A must-have is something version one cannot function or be tested without. A nice-to-have adds value but could be delayed to a later release without breaking the core experience. Sorting features into these two buckets before development starts is one of the most effective ways to keep an MVP focused.

Should I fill out this worksheet before or after validating my idea?

After you've done at least some basic idea-shaping — defining the problem, customer, and core assumption. This worksheet turns that thinking into a concrete document you can hand to a developer; it isn't a substitute for the thinking itself.

Can I change my answers on this worksheet later?

Yes, and you likely will as you talk to real users or get feedback from a development team. The point isn't to lock in permanent answers — it's to have a clear starting position so changes are deliberate decisions rather than accidental scope drift.

What happens after I've filled out this worksheet?

The next step is usually a technical preparation pass — turning your answers into requirements, wireframes, a tech stack decision, and success metrics a development team can build against. That's a separate, more technical checklist that follows this worksheet.