Scoping an MVP: turning a broad idea into a buildable plan

"I want to build a tool that helps freelancers manage their business" is an idea. It is not a plan, and it's not buildable as stated - there's no clear starting point, no way to know what to cut, and no obvious definition of done. Scoping an MVP is the process of turning that kind of broad statement into something specific enough to actually build: a prioritized list of features, phased into what ships first versus what waits.

Start from the hypothesis, not the feature list

The instinct when scoping an MVP is usually to start brainstorming features. That's backwards. The features that matter are the ones that let you test your riskiest hypothesis - the specific, falsifiable claim about who has this problem and what they'd actually do about it. Everything else is scope creep dressed up as thoroughness. If a feature doesn't directly help you find out whether the hypothesis is true, it doesn't belong in the first version, no matter how obviously useful it seems in the abstract.

Break the idea into features honestly

Take the broad idea and force yourself to list the actual, discrete pieces of functionality it implies - not vague capabilities ("manage their business") but specific things a user does ("log an expense," "send an invoice," "see monthly totals"). This step alone usually surfaces how much bigger the full idea is than the mental picture in your head. A "simple" freelancer tool routinely decomposes into ten or fifteen distinct pieces once you actually write them all down, which is exactly why this step matters - you can't prioritize a list you haven't made explicit.

Prioritize by what the hypothesis actually needs

Once the list is explicit, sort it against a single question: does this feature help test the riskiest assumption, or does it just make the product feel more complete? "Log an expense" and "send an invoice" might both be core to the persona's workflow and worth testing early. "Multi-currency support" or "a mobile app" might be genuinely valuable eventually and completely irrelevant to whether ten target users will actually use the core loop. The goal isn't to build the smallest possible product for its own sake - it's to build the smallest product that gives you an honest answer to the question you're actually trying to answer.

Phase what doesn't make the cut, don't discard it

Features that lose the prioritization pass aren't wasted work - they're phase two, three, or later, and writing that down explicitly matters for two reasons. First, it keeps a good idea from getting lost just because it didn't make the first cut. Second, it protects you from the opposite failure mode: quietly re-adding "just one more thing" to the MVP every time a deprioritized feature comes back to mind, which is how MVPs stop being minimal. A clear, phased plan - not just an unordered backlog - makes it easy to say "yes, and it's in phase two" instead of either dropping the idea or blowing up scope.

Write the plan sharp enough to hand off

The real test of whether an MVP is properly scoped is whether you could hand the plan to someone else - a co-founder, a contractor, or an AI coding tool - and have them start building without a clarifying conversation first. That means each feature needs enough detail to be unambiguous: what the user sees, what happens when they take the core action, what the edge cases are. "Users can log expenses" isn't detailed enough to build from. "A user adds an expense with an amount, category, and optional note; expenses show in a running list sorted by date; the monthly total updates live" is. The gap between those two sentences is usually the gap between a plan that sounds reasonable in a conversation and one that actually survives contact with a build tool.

Don't forget distribution while you're scoping

It's easy to treat distribution as a problem for after launch, but for most consumer and prosumer products, distribution is closer to make-or-break than any individual feature choice - a technically solid product that nobody hears about performs identically to a product that doesn't exist. While you're scoping the MVP, it's worth asking the same rigor-first question about distribution that you asked about features: what's the actual, named channel this reaches its first real users through - not "marketing" as a category, but a specific community, platform, or existing relationship you can point to. A plan that nails the feature scope but has no answer to that question is still an incomplete plan.

The shape of a good MVP plan

By the end of this process, a properly scoped MVP looks like: a small, prioritized set of features that exist specifically to test the riskiest hypothesis, each one detailed enough to build without further clarification, an explicit phase-two-and-beyond list for everything that didn't make the cut, and a real answer for how the first users actually find out the thing exists. That's a genuinely different artifact from a broad idea statement, and it's the difference between a weekend of building that produces a real answer and a weekend of building that just produces more code. Nucleus is built to help with exactly this step - turning a validated idea into a scoped, phased, build-ready plan reviewed from angles a solo founder tends to miss, sharp enough to hand straight to whatever tool you're using to actually build it.