How to validate a business idea before building software

Start with the customer and the problem, not the app

Write down who experiences the problem, when it happens and what they do today. 'Small businesses need automation' is too broad to test. 'Independent training providers copy booking requests from email into a spreadsheet each afternoon' describes a situation you can investigate. That example is hypothetical, not a claim about a particular client or sector.

Separate the person using the product from the person paying for it. A staff member may dislike the current process while a business owner sees no reason to fund a replacement. You need to understand both the operational friction and the decision to buy, including procurement or approval steps.

Choose the riskiest assumption first. If you cannot reach likely buyers, the immediate test is distribution. If buyers are easy to reach but already have an adequate solution, the test is whether your difference matters. A polished interface cannot answer either question on its own.

How do you run useful customer interviews?

Ask people to describe a recent real instance of the problem. Explore the steps, the tools involved, the time spent and the outcome. Questions about past behaviour provide more concrete evidence than asking whether someone would use an imaginary app. Avoid explaining your product at the beginning: that can turn research into a sales conversation.

Recruit beyond friends and people who want to encourage you. Look for people who actually handle the workflow and people who control spending. Keep notes of contradictions and lack of interest as carefully as positive feedback. Repeated stories can help you spot a pattern, but a small set of interviews does not represent an entire market.

• When did this last happen? Walk me through what you did.
• Which part caused the most trouble, and what happened as a result?
• What tools or services do you already use to solve it?
• Have you tried changing the process? Why did that work or fail?
• Who would approve buying an alternative?

Check existing alternatives and willingness to switch

Competition includes spreadsheets, messaging apps, an employee's time and deciding to do nothing, not only other startups. Map these alternatives against the specific problem. A new product may save effort but still be unattractive if switching requires staff training, data migration or a change to an important business relationship.

Review competitors' public offers, onboarding steps and customer feedback without treating marketing claims as verified facts. Use this to improve your interview questions, not to assert that the market needs another version of the same tool. Ask what would make a customer change and what would make them stay with the current solution.

Discuss an actual offer rather than a vague price question. What outcome would they receive, what work would they need to do and what commitment would be required? Someone saying 'that sounds useful' has not shown the same intent as agreeing to a scheduled pilot or purchasing a clearly described service.

Choose an experiment that answers one question

A landing page tests whether an offer prompts action from the audience you reach. It does not prove retention or product quality. A clickable prototype tests whether people understand a workflow, but not whether they will pay. A manually delivered pilot can test the value of the outcome while leaving much of the software unbuilt.

For the hypothetical training-provider idea, an experiment could be a shared booking process managed manually for a willing business. Observe whether it reduces confusion, whether staff continue to use it and what support is needed. If the business will not make time for the trial, investigate why before interpreting the problem as validated.

Be transparent. Label a waitlist as a waitlist, distinguish a concept from an available product and do not invent customer testimonials. If taking money for a pilot or pre-order, make delivery expectations, limitations and cancellation arrangements clear and seek professional advice where appropriate.

Use a simple validation worksheet

Keep one record for each assumption with the test, the observation and the decision. This prevents a collection of positive comments from being mistaken for a coherent business case. Set criteria before the experiment, and explain what remains uncertain afterwards.

An illustrative worksheet might read: assumption — staff need a shared booking queue; test — a manually supported pilot; evidence — completed requests, repeat usage and time spent resolving mistakes; decision — build only if the shared process helps enough to justify its operating cost. These are example fields, not universal success targets.

• Assumption: what must be true for the business to work?
• Test: what is the smallest honest way to investigate it?
• Signal: what commitment or behaviour will you observe?
• Limit: what will this experiment not establish?
• Decision: continue, revise the offer, run another test or stop?

Common validation mistakes to avoid

Do not confuse traffic with demand. A broad advertising campaign can generate visits from people who are curious but not potential customers. Keep the audience, message and resulting action visible so you can understand why the experiment produced its result. A waitlist with no clear next step can overstate interest.

Do not ask an AI assistant to invent your customer research. It can help organise interview notes or draft questions, but generated responses are not evidence from customers. Review its summaries against the originals, and avoid sending identifiable interview information into a tool without considering the data-handling arrangements.

Do not require every experiment to support the initial idea. Learning that buyers prefer a simpler service, a different workflow or no change at all may save a larger investment. Keep a decision log so the first release reflects what you learned rather than what the original pitch promised.

When are you ready to commission an MVP?

You are in a stronger position when you can name reachable customers, explain the problem in their words, describe existing alternatives and show a meaningful commitment to your offer. That is not a guarantee of success. It is enough context to discuss a focused experiment or first release instead of paying to discover everything during development.

Bring your interview findings, test results and unresolved questions to a development conversation. CodeCue can discuss software, SaaS and interface design around that evidence. A suitable proposal should identify what the first release will test, how its results will be reviewed and which features should wait.