How to test an idea before spending money building it

Start with the assumption that could change your decision to build. Find people who experience the situation, ask what they do now, and run the smallest honest test of a proposed solution. Look for actions as well as opinions. Early testing can reduce uncertainty; it cannot guarantee that an idea will succeed.

1. Turn a big idea into one question

“Will people want this?” is too broad to test well. Break it into questions: Does this situation happen often? Is the current workaround good enough? Will someone change their routine? Can the proposed solution do its job? Pick the question whose answer would most change what you do next.

This is an invented teaching example, not a customer story or a result produced by Has Legs. You can use the same approach for a community project, a service or a physical product.

2. Ask for the last real example

Speak with people who actually face the situation. Start with recent experiences before showing your solution. Friends can help you practise, but encouragement from friends is different from evidence from intended users.

• “Walk me through the last time you prepared an invoice from a crew update.”
• “Where did the information come from?”
• “What did you have to ask again, if anything?”
• “What do you use now, and what works well about it?”
• “Who would decide whether to try a different process?”

Ask permission before taking notes or recording. Keep only what you need for the test, and avoid collecting customer records or confidential job details. An anonymized description may be enough.

3. Test the process before building the software

For the contractor example, make a one-page handover template with fields for the job reference, work completed, changes and unresolved questions. With permission, ask a small number of owners to try it on a suitable job. The crew can fill it in using a simple form; the owner can review it manually. Explain that this is a trial, not a finished automated product.

Now observe: do people complete it, what is missing, and does the owner still need to chase the same information? You are testing whether the handover is useful. You have not yet tested whether an app can automate it, whether it will work at scale, or whether people will pay.

• App idea: link a few screens and watch someone attempt one task. This tests understanding and navigation, not reliability or market demand.
• Physical product: use a sketch or safe, non-working model to discuss fit and handling. This does not establish strength, durability or manufacturing readiness.
• Service or event: offer a clearly described small pilot that you can actually deliver. Attendance or repeat participation can tell you more than likes alone.

4. Write your decision rule before you start

Choose a time limit, an effort limit and the behaviour you hope to observe. Do not invent a universal “pass rate.” Your threshold should reflect the decision in front of you, and a small convenience sample will not represent the whole market.

For the handover example, a useful rule could be: continue to a second trial if owners use the summary for a real invoice and ask to keep using it. Revise the template if they still need to chase essential details. Reconsider the approach if their existing process already handles the job well. These are suggested decision rules, not results.

5. Choose a tool for the next experiment

• Google Forms →

  Collect structured responses for a simple handover or research form. Ask only for information you need.

• Figma prototyping →

  Connect proposed screens to test whether someone can follow an app flow before development.

• Our tool-selection guide →

  Compare cost, export options, learning effort and the information a tool needs before committing.

Paper, a document or a spreadsheet may be enough. The external tools above are examples, not required purchases or integrations with Has Legs. Check their current plans and sharing settings before using them.

6. Decide what the evidence actually supports

“They liked the sketch,” “they tried the workflow,” “they returned,” and “they paid” describe different behaviours. Record each accurately. A person requesting a second trial is a useful signal, but it is not proof of a sustainable business. If willingness to pay is your next question, test a clearly explained offer that you can fulfil; do not treat a waitlist or an enthusiastic comment as a sale.

Summarize what you saw, what surprised you and what remains unknown. Then choose one next action: repeat the test with different users, simplify the idea, investigate a technical constraint, or stop spending on this version.

Use Has Legs to turn the thought into a plan

You can talk or type the messy version into Has Legs, then work through follow-up questions by voice or typing. Your Idea Brief brings the concept, intended users and a possible first step together. An optional paid Action Plan takes it further with a fuller idea breakdown, practical next steps, tests, tools and prototype planning where relevant. You still need to run the real-world tests; Has Legs helps you decide what to investigate.

See what you get with a Brief and an Action Plan.