MVP Scoping and Build

Name the one bet your first product tests, cut everything else, build it inside a fixed time box and put it in front of real users within weeks, with pass and fail lines set in advance.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Then open the Marketplace in the app, search for MVP Scoping and Build, and click Install. It goes into your own files, and works offline from then on.

What it installs.

1

Pillar

1

Area

50

Projects

200

Starter tasks

🚀 Founding & Startups

MVP Scoping and Build

Deciding the smallest product that tests the core bet, cutting scope ruthlessly and shipping it to real users within weeks.

  1. One-sentence core bet for the first product
  2. Riskiest assumption map before any code
  3. Pass and fail thresholds set before launch
  4. Six-week build time box and ship date
  5. Choosing concierge, Wizard of Oz or coded MVP
  6. User story map of the single core flow
  7. Must, should, could and cut list
  8. One-page MVP spec the whole team signs
  9. Clickable prototype tested before code
  10. Monday scope review against the cut list
  11. Daily build note and blocker log
  12. Friday demo to someone outside the team
  13. Weekly bug triage with a severity rule
  14. First-user feedback inbox and tagging
  15. Twice-weekly small release habit
  16. Shortcut and tech debt ledger
  17. Manual operations behind the MVP
  18. Cloud and tool spend cap for the MVP
  19. Watching recorded user sessions twice a month
  20. Writing user stories with acceptance criteria
  21. Instrumenting the core bet with five events
  22. No-code MVP builders tried hands-on
  23. Running a five-user usability test
  24. Estimating build work in ranges
  25. Technical spike on the scariest feasibility risk
  26. Reviewing a build as a non-technical founder
  27. Minimum security and privacy baseline
  28. Build in-house, freelancer or agency decision
  29. Fixed-scope contract with an outside developer
  30. Removing the sign-up wall from version one
  31. Deciding how the MVP takes money
  32. Faking integrations with manual imports
  33. Mid-build scope cut when the date slips
  34. Throwaway or keeper code decision after the MVP
  35. Second-version request triage
  36. Internal dogfood week before first users
  37. First cohort of twenty invited users
  38. MVP go-live day checklist
  39. Two-week readout against the thresholds
  40. MVP retrospective with everyone who built it
  41. Live demo of the working MVP for investors
  42. Engineer founder's guard against over-building
  43. Solo founder building the MVP alone
  44. Ten-hour-a-week MVP alongside a day job
  45. Splitting build and customer work between co-founders
  46. MVP scoping in a regulated domain
  47. Mobile MVP through app store review
  48. Feature flags and staged rollout
  49. Single-user value before network effects
  50. Data model and migration plan before real data

Where it starts.

Each project arrives with its purpose, milestones and first tasks written out. Here is how the first three read.

One-sentence core bet for the first product

Most first products fail to teach anything because nobody wrote down what they were meant to prove. A single sentence in the form "we believe this user will do this action because of this value" turns a vague product idea into a test, and every later scope argument can be settled by asking whether a feature helps answer it.

First tasks

  • Write three drafts of the core bet sentence in twenty minutes
  • Pick the draft whose failure would hurt the company most
  • Read it to a co-founder and ask them to repeat it back
  • Pin the agreed sentence at the top of the build board

Riskiest assumption map before any code

Every product idea rests on a stack of assumptions about desire, ability to deliver, willingness to pay and reach. Mapping them by how uncertain they are and how fatal they would be shows which one the MVP must test first, and often reveals that the riskiest one needs no code at all.

First tasks

  • List every assumption the core bet depends on in one sitting
  • Score each one for uncertainty and impact from one to five
  • Circle the assumption with the highest combined score
  • Write what evidence would prove that assumption false

Pass and fail thresholds set before launch

After launch, any number can be explained away as early, noisy or promising. Agreeing in advance that, say, 30 percent of invited users must complete the core action twice in two weeks gives the team a line that decides the next step instead of a debate.

First tasks

  • Choose the one user action that best shows the bet is true
  • Write a pass number and a fail number for that action
  • Agree how many users and how many days the test needs
  • Write what you will do after a pass, a fail and a grey result

Make it yours.

Install MVP Scoping and Build, then tell Aurum the date you're aiming for. It checks whether the plan fits the weeks you actually have.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Blueprints are general information to help you organise your own work. They are not medical, financial, legal or other professional advice. See the Terms.