Scope creep is not a character flaw; it is the default state of building without a stated question. A first product — an MVP in the software sense or a first SKU in the physical sense — exists to answer a specific, falsifiable question about the market, such as "will salons pay for appointment reminders that reduce no-shows?" Everything on the build list either serves that question or postpones the answer. Orer News publishes information, not business advice.
The scope discipline is the same in both worlds: define the question, list what is required to answer it, and treat everything else as version two.
What is the question this build answers?
Write it down in one sentence with a measurable outcome: who pays, for what, at roughly what price. If the sentence cannot be written, the build is not ready to start — you will be unable to reject any feature, because no feature can fail to serve an unspecified goal. Teams that skip this step ship the average of their guesses eighteen months late.
What belongs in version one?
Three layers, in order: the core value delivered one time — the reminder sent, the meal cooked, the report generated; the minimum wrapper to take payment — even a manual invoice or a checkout link; and the thinnest feedback loop — a way to learn whether the value landed. Conspicuously absent: accounts systems, settings pages, multiple pricing tiers, mobile apps when the job can be done in a browser, integrations, admin dashboards. Each is defensible in version two and indefensible while the core question is unanswered.
What can be done by hand instead of built?
The classic scoping lever is replacing software with labor in early versions: concierge onboarding performed manually, reports assembled by spreadsheet, orders fulfilled from a home workshop. Manual work does not scale, and that is precisely the point — it caps the blast radius of a wrong guess while revealing which parts customers actually touch. Shopify famously began as the storefront for a snowboard shop whose founders sold equipment online before writing the platform; the pattern is standard. If a process must be built eventually, running it by hand first also writes the requirements from experience rather than imagination.
How do you hold the line against additions?
Mechanical rules work better than willpower. Every proposed feature is written on a list, not discussed — the list is reviewed only after the core question is answered. Deadlines set by calendar rather than task completion force scope to flex downward, since the date holds and the feature list yields. And a written definition of done for version one — the single sentence question plus its measurement, plus the ship date — gives every later debate an arbiter that is not the loudest voice in the room.
When is version one too small?
There is a real floor: the product must deliver the core value completely for at least one real customer type. A version that demos but does not perform the core job answers nothing, because its failure is uninformative — customers rejecting a broken thing tells you about the brokenness, not the demand. The test of minimum scope is not how little you built but whether the value delivered is whole. Ship the smallest complete answer to the question.
- One-sentence question with a who-pays outcome
- Value, payment, feedback — the three version-one layers
- Do manually whatever can be done manually
- Feature requests go to a list reviewed after launch
The first product's job is not to impress; it is to find out. Scope it like the experiment it is, and let version two be designed by customers instead of by committee.
For more context, read What a Seed Deck Needs to Survive the First Three Minutes.
For more context, read bootstrapping vs funding.
For more context, read How to Validate a Business Idea Before You Quit Your Job.