What to validate before paying to build an MVP

Start with the assumption that could stop the project

Write down the conditions your idea depends on. Separate customer demand, buying decisions, usability and technical feasibility. Ask which unproven condition would force you to change the product most substantially.

For example, imagine a Brisbane startup proposing a job-handover tool for small trade businesses. The owner likes the dashboard, but the idea depends on field staff entering job notes. The first test should explore that behaviour in the working day. Polishing the dashboard would leave the central risk unresolved.

For a specialist product sold internationally, narrow the audience in the same way: a particular role, recurring task and buying context. Geography alone is too broad a starting point.

Choose a test that can answer that question

• Demand: Ask potential customers to describe the last time the problem occurred, how they handled it and what it cost them in time or effort. Look for a recurring problem and an existing workaround.
• Usability: Give likely users a realistic task in a clickable prototype. Observe where they hesitate or need help. Successful task completion gives evidence about the proposed interaction; it does not establish willingness to buy.
• Buying: Discuss a clearly scoped pilot with the person who controls the budget. Explore the price, approval steps, timing and conditions for participation. A booked next step or agreed pilot scope is more actionable than a general compliment, although neither guarantees a sale.
• Feasibility: Commission a small technical spike when the product depends on an uncertain capability. Test the actual integration, representative data and relevant access limits. A polished demo with fabricated responses cannot establish that the integration works.

You may need several tests, but sequence them around the biggest risk. Use sample data where possible and make clear to participants which parts are prototypes or manually operated.

Agree what would change your mind

Before testing, record the assumption, who will participate, the behaviour you expect and the result that would justify the next step. Choose thresholds for your situation rather than borrowing a universal conversion target.

Keep the evidence precise. A waitlist entry shows interest in the offer presented. It leaves questions about repeat use, payment and delivery unanswered. An unsuccessful test also needs interpretation: did the idea fail, or did you recruit the wrong people or create an unusable test?

Turn the findings into a smaller build brief

A development brief should carry forward the target user, one complete journey, the evidence gathered and the assumptions still open. Separate launch essentials from later ideas. Include acceptance criteria, operating responsibilities and how the first release will measure real use.

Prototype code may need replacing or hardening before launch. Clarify what you are purchasing, who owns the work and what must be checked before real customers depend on it.

Use Tej Studio’s software project brief guide to organise those findings. If you need help choosing the next test or shaping a focused release, discuss your MVP with Tej Studio.