How to scope the smallest version that proves it

The instinct with a new idea is to imagine the finished, polished thing and try to build all of it. That is the slow, expensive path, and it delays the only thing that matters early: finding out whether the idea works at all. Scoping the smallest version is the discipline of building just enough to learn, and no more.

Step by step

1. Name the one thing that must be trueBefore scoping anything, decide what you are trying to prove. It is usually one thing: that people with this problem will actually use a tool like this, or pay for it. Write that sentence down and keep it visible. Everything you scope is now in service of answering it, and anything that does not help answer it can wait. A clear question keeps the build small, because once you have it, most features reveal themselves as things that do not actually help answer it and can therefore be set aside for now.
2. Strip the idea to its single core actionFind the one action that is the entire point and picture a version where a user can do only that. No account settings, no dashboard, no polish, just the core act working end to end. This feels uncomfortably bare, and that is correct. If that bare version would still teach you whether people want it, you have found the smallest version worth building.
3. Cut everything that only supports or decoratesGo through your feature list and, for each item, ask whether the core action can happen without it. Logins, admin screens, settings, notifications, styling, all of it is support or decoration around the one act. For a first proof, most of it can be faked, deferred, or done by hand behind the scenes. Ruthless cutting here is what keeps the build cheap and fast enough to actually happen.
4. Decide what you can fake or do manuallyMuch of what feels essential can be handled by a human for the first version. Matching can be done by you in a spreadsheet, a confirmation email can be sent by hand, a report can be written manually. Doing things manually behind a simple front end lets you test the idea without building the machinery, and it teaches you exactly how the work should behave before you pay to automate it. If the manual version proves demand, you then know exactly what is worth automating, and if it does not, you have saved yourself the cost of building machinery for a thing nobody wanted.
5. Set a hard limit and protect itWrite down what the smallest version includes and, explicitly, what it does not. Then guard that boundary, because scope creep is relentless: every good idea for a later feature will try to sneak into the first build, each one sounding reasonable on its own. Note the good ideas on a separate list for later and keep the first version small. The whole value of a small build is lost the moment you let it quietly become a big one, because the point was to learn fast and cheap, and every added feature costs you both speed and money before you have earned the right to spend them. Hold the line, and the small version stays small enough to actually finish.