Know If Your Idea Is Worth Building: A Founder's Minimum Viable Test

You can stop guessing whether your startup idea is worth building. A staged pre-build test sets a go/no-go threshold before you spend weeks on code.

Gagan Biyani, a repeat founder and CEO of Maven, created a Minimum Viable Test to check an idea before construction. He says he was an early participant in four companies, and that three reached over $1M run-rate during their first six months after launch.

It asks for evidence in the order a buyer would experience it: pain, willingness to pay, and a reason to act now.

Start with the buyer, not the product

Name the buyer you would serve and the painful problem they already have. You are done when a stranger could repeat the description without your help. If you cannot name the buyer, the test has no target.

Ask about the current workaround, not the imagined future. A buyer who already spends time, money, or effort on a fix is easier to understand than a buyer who only agrees with your vision. Write down what they do today, what breaks, and what they have tried before.

Bob Moore, a repeat founder, evaluated startup concepts by consulting other founders instead of relying solely on prospective buyers. That founder-discovery process led him to select the idea that became Crossbeam.

Some teams begin with a list instead of a problem. Ryan Noon and Abhishek Agrawal of Material Security began without a defined problem and reduced a list of startup concepts to four. That approach can work, but it still needs a buyer to make the choice concrete. The buyer defines the problem. The product is the answer you test against that problem.

Set the stop line before you spend

Write the go/no-go threshold before you collect evidence. The line says build, pivot, or stop, and it includes the buyer count, the payment signal, and the time limit you will accept.

Keep the threshold small enough to act on. A line that requires perfect proof can stall you. A loose line can let you build on hope. The threshold should be something you can check with a calendar, a spreadsheet, or a simple yes/no list.

For example, say you will build only if one buyer agrees to pay and another agrees to a call. If the payment does not happen, you stop. If the call does not happen, you pivot the problem or the buyer. Write the example in the same document as the threshold.

Avitechon says he has observed hundreds of startup concepts fail because founders omitted the validation step. A threshold turns a vague hunch into a decision. It also gives you a place to stop when the idea feels attractive. If you cannot say what would change your mind, write that gap down and close it before you build.

Run the test before you build

Ask for a payment commitment from a real buyer. Done means a deposit, a written commitment, or a scheduled paid pilot. The trap is treating enthusiasm as payment.

Payment does not have to be a full invoice. It can be a refundable deposit, a consultation fee, or a small pilot fee. The point is to move the buyer from interest to a transaction. If the buyer will not commit, ask what would make them commit. Their answer is part of the test. Keep a simple log of who you asked, what they said, and what they committed to. Review the log against the threshold before you start building.

Use Biyani's result as a benchmark, not a promise. Your test ends with a decision: build, pivot, or stop. When the buyer will not pay, the idea is not ready, no matter how strong the demo feels.

Run the same sequence for each shortlisted idea. Do not let a flattering conversation override the threshold. When the evidence is in, make the call and write it down.