How to test your MVP

You do not need to build the whole product to run a first test. You need a question, a task that gives evidence about it, and a way to observe what happens.

This example uses v0 to make a small browser prototype. You could run an earlier test with paper or a manually delivered service instead. The tool is useful only if the result helps answer your question.

1. Make the idea testable

Suppose you want to help freelance designers prepare a project handoff. Your idea is a tool that turns a checklist into a concise handoff note. You suspect designers forget to explain what files are ready and what the client needs to do next.

For this first test, ask: Can a designer use a short form to create a handoff note they consider useful enough to adapt?

This is a usability and usefulness question. It is not yet a test of whether people will pay, use the tool repeatedly, or trust it with real client information. Choose three to five people who regularly hand off design work as an initial convenience sample. That is a practical starting point, not a statistically representative sample or a requirement.

The task has one clear outcome: enter example details, create a note, then copy or edit it. Use fictional project details so the test does not require client names, private files, or other sensitive information.

Before the sessions, choose an illustrative decision rule. For example, invite five designers and plan to investigate the concept further if at least three independently reach a note and say they could adapt it for a handoff. If all five participate and fewer than three do, investigate the task or value before adding features. If fewer than five participate, record the shortfall and treat the threshold as inconclusive. This is a practical rule for deciding what to do next, not proof of demand or a statistical standard.

2. Ask v0 for the smallest flow

According to the v0 quickstart, you can sign in, start a new chat or project, describe what you want, and refine the generated application through conversation. Start with a prompt like this:

Build a simple browser prototype for freelance designers to prepare a project handoff note. Use fictional data only. Show fields for project name, completed deliverables, files or links to include, and the client's next action. When I select Create note, show an editable plain-text note using the entered details. Add a Copy button and a clear message when a required field is empty. Do not add sign-in, a database, analytics, email sending, or payments. Make the page usable on a phone and a laptop.

The prompt states the user, task, output, boundaries, and a few behaviors to check. It does not assume that generated code works correctly. Review the result in the preview and ask for a focused change when a step is missing. For example: “The note does not include the client's next action. Include it and keep the rest of the flow unchanged.”

You can generate a draft without an AI text service: the prototype can assemble a note from the fields. If your real question is whether an AI-generated note improves the result, this version will not answer it. Design that comparison as a separate test.

3. Check the flow yourself

Before another person sees it, walk through the task with sample data:

1. Leave a required field blank and check that the message tells you what to fix.
2. Enter a fictional project and create a note. Check that each detail appears in the right place and that the note does not invent facts.
3. Edit and copy the note. Paste it somewhere to check the copied result.
4. Refresh the page and check what happens to the entered text. Tell participants if it is lost.
5. Check the layout and controls at the screen sizes participants will use.

These checks are examples, not a security or accessibility certification. Inspect the generated code and data behavior if you plan to handle real information. Do not add secrets or client data just because the preview appears to work. Fix failures that would prevent the test from answering its question.

4. Invite people to try the task

Ask each participant to imagine they have finished a fictional design project. Give them sample deliverables and a next action, then ask them to prepare a handoff note. Avoid showing them where to click first. Watch where they hesitate, whether they reach an editable note, and what they change.

If a participant is comfortable with it, record brief notes on the steps they completed and their comments. Ask afterward: “What would you change before sending this?” and “How does this compare with what you normally do?” Do not treat a polite “I like it” as evidence they would adopt it.

The v0 deployment guide describes publishing to a production URL. Publishing makes the application accessible on the web, so review what is exposed before using that route. For an early session, you can instead show the preview yourself and let the participant direct the task. If you operate the controls, you can hear their instructions and observe their reasoning, but you cannot claim they navigated independently. Record this difference and do not count a facilitator-operated session toward the independent-completion threshold above. Do not describe a public URL as private or assume it is suitable for real client data.

5. Interpret what you saw

Record the number of participants who started, reached a note, edited it, and copied it, along with the reason for any interruption. If someone copies the note, you observed a copy action, not a client handoff. Ask whether it would fit their actual work, but treat that answer as a follow-up lead rather than proof of future use.

For example, imagine five designers try the flow independently. Three reach a note they say they can adapt, meeting the proposed threshold, but all three replace the generic next action. One of the other two stops because they need to attach files rather than list links. This fictional result suggests that next-action wording and file handoff deserve investigation. It does not prove a market, a retention rate, or that file storage is the next feature to build. Check how people currently share files and what access controls they would need before deciding.

If the flow was too confusing, repair it and repeat the task. If the flow was easy but the note did not help, revisit the problem or the output. If people find it useful, run a next test in a real workflow with appropriate consent, data protection, and a clear way to learn whether they return or pay.

When you know you need a lasting application rather than a short prototype, decide which foundation fits its data, access, and operating requirements. Our guide to building from scratch or using a starter covers that choice.