Key takeaways
A testable hypothesis needs a named user, a specific action, and a measurable outcome, or it can't prove anything once built.
Cutting scope means removing anything that doesn't test the stated hypothesis.
Poor product-market fit is a common reason startups fail, so proving the right assumption outranks building fast.
A clickable prototype can test usability; a working MVP lets users complete the core workflow so you can measure its outcome.
AI-assisted building is standard practice among new developers, so it's a mainstream path for an MVP.
The idea is scoped, and the assumption behind it is clear. But there’s no engineering queue waiting for it, and paying a developer for a prototype you might scrap in three weeks makes little sense.
A minimum viable product (MVP) gets past both problems by turning one specific, testable assumption into working software that real users can open and use, so you get signal from real behavior. A pitch deck, a mockup, or a Notion doc with screenshots can't do that job.
What your MVP needs to prove
Your MVP exists to test one falsifiable assumption through real user behavior. A prototype shows whether users understand an interface. Only a functioning MVP shows whether they complete the core workflow tied to your intended outcome.
That distinction outweighs build speed. CB Insights' analysis of VC-backed shutdowns found that 43 percent of the 385 with identifiable failure reasons cited poor product-market fit. Building fast in the wrong direction doesn't shorten that path.
Every scope cut, tool choice, and agent decision in the steps that follow runs through one filter: Does this help prove or disprove the stated assumption?
Step 1: Define your one testable hypothesis
A usable hypothesis names:
one user segment
one observable action
one measurable outcome
a success threshold
a test period
Write it so evidence can prove it false.
A weak hypothesis reads like a vision: "Small business owners will love our invoicing tool." A strong one reads like a bet: "Freelance designers will create and send an invoice within ten minutes of signing up, and 60 percent will do so in the first two weeks." The second version can fail. The first one can't.
Y Combinator Group Partner Michael Seibel offers a Startup School lesson on building an MVP, covering how to determine your feature set and put it in front of early customers. That discipline starts with one testable claim.
Step 2: Cut scope to the smallest testable version
Cutting scope means removing anything that doesn't test your Step 1 assumption. The smallest testable version tests that one assumption; the smallest version of your whole product still carries features the test never touches.
Apply this filter to every candidate feature. If cutting it doesn't change whether your bet gets proven or disproven, remove it. Auth flow stays if your hypothesis requires a logged-in user to complete the action. A polished onboarding animation goes, because it doesn't touch the measured behavior.
Step 3: Choose your build path: code, no-code, or AI builder
The right build path follows the technical complexity your test claim demands. Each path trades speed, skill requirements, and flexibility differently.
Criterion | Custom code | No-code or low-code | AI builder |
Speed to a working build | Weeks to months, gated by engineering capacity | Days to weeks, depending on the platform and how much you configure | Hours to days, depending on scope and testing |
Team and skills required | Engineers who write and maintain code | Non-engineers assembling visual components | Non-engineers prompting in natural language |
Real, exportable code | Full ownership, code lives in your repo | Varies by platform: some export code, others don’t | Generates real code, exportable to GitHub |
Handles complex, interconnected features | Supports complex features, with engineering expertise | Depends on the platform, from built-in workflows to custom backends | Depends on the platform, agent, and integrations |
Ask whether your hypothesis requires interconnected backend logic, real authentication, or real data. If yes, custom code gives you full control but assumes an engineer is available.
No-code tools move faster than custom code, though what they can build depends on the platform, so check it against your assumption's data model. AI builders can generate authentication and database logic from a prompt without an engineer.
These categories overlap. AI builders generate real code that engineers can extend like any custom codebase, and some no-code platforms now add AI features and code export. Choose by what your test claim requires.
GitHub’s Octoverse report found that nearly 80 percent of new developers on GitHub use Copilot within their first week, which shows how standard AI-assisted building has become.
Step 4: Build it in Bolt.new
Carry the hypothesis and the cut scope from Steps 1 and 2 straight into Bolt.new without reopening product decisions. Pick the agent that matches your scope, prompt that exact scope, and publish a live URL.
The path scales past prototypes. Digital Virgo’s CTO, Julien Menard, reports cutting time to launch from 12 months to 3.5 months and shrinking a team of four or five to one primary architect.
Match the agent to your scope
Use Standard for a well-defined single-hypothesis build and Max when the scope you cut in Step 2 still contains interconnected or complex features. Standard is balanced and token-efficient, suited to small and medium apps with clear, bounded tasks. It’s also the only agent on the Free plan, so testing a simple bet doesn’t need a paid upgrade.
Max applies deeper reasoning to each step, making it the right choice for connected workflows, multi-step logic, or substantial data relationships. It’s a paid-plan feature, so move to Max only if your cut scope still needs it.
Bolt.new handles model selection behind the scenes. You pick the agent; Bolt.new picks the model.
Prompt your scope into a working app
Your build prompt should restate the hypothesis and scope from Steps 1 and 2 word for word. Name the user segment, the action they need to complete, the measurable outcome, and every feature you cut.
Example prompt: Build a web app where freelance designers sign up with email, create an invoice, and send it to a client. On an admin page, track all signups during a two-week test and show the percentage who send their first invoice within ten minutes of signing up. Leave out payments, recurring invoices, and client accounts.
Before Bolt.new writes any code, use Plan Mode to walk through the build structure and confirm it matches your scope. Tag specific files or folders with @ to keep the agent focused on only what the test claim requires.
Once the build runs, open Code View to inspect the result and refine it with follow-up prompts, all without writing code.
To see this flow end to end, try the Bolt.new AI app builder with your Step 1 hypothesis.
Ship it live with Bolt Cloud
Bolt Cloud publishes your MVP to a live URL, so real users can try it.
If your assumption depends on persistent user behavior, prompt Bolt.new to add signup and login before you share the link. Every project includes unlimited databases, created automatically when needed, so you don't set up a database separately. Test the auth flow yourself first:
Sign up.
Log in.
Complete the core action end to end.
If you already have infrastructure preferences, Netlify publishing and Supabase databases are both supported alternatives, with the Supabase integration available on Pro and Teams plans. Bolt Cloud is the integrated path but remains optional.
Step 5: Put your MVP in front of real users
Give the live URL to the exact user segment your hypothesis names, then let that segment use it. A broader audience, a screen recording, or a demo deck can't test the hypothesis.
At the end of your test period, compare the results with your success threshold. For the invoicing example, did at least 60 percent of signups send an invoice within ten minutes? If the result falls short, check whether users abandoned a working flow or encountered a technical failure.
When investors or stakeholders need the evidence, use Bolt Slides to present the working MVP and your findings together. The deck ships as a live link they can open and test after the meeting, and Bolt Slides is available on Free and paid plans. The live component lets stakeholders try the workflow, while your test results show whether users met the success threshold.
Common mistakes that derail the build step
Three execution failures kill an MVP after the planning work is done:
scope creep
a mismatched build path
a mockup shipped in place of a working app
Scope creep starts with one feature. You defined the boundary in Step 2, then added one feature mid-build because it felt small. Each addition takes time and can make the test results harder to interpret.
If your hypothesis requires authentication or a database write, a static mockup produces no evidence either way. Pushing complex, interconnected logic into a tool built for basic workflows breaks the app where the bet needs it to hold.
Build it, ship it, then test your hypothesis
A hypothesis proves nothing until a real user acts on it, and that takes a live app.
You describe the scoped feature set, and Bolt.new plans and writes working software in the browser with no local setup. Bolt Cloud then publishes it, with hosting and authentication in the same project, so you don't need an engineering queue or a second vendor.
The hypothesis you wrote in Step 1 and the scope you cut in Step 2 are enough to ship something testable today.
Start building now by pasting both into Bolt.new, and publish a live app real users can test for free.
