How to test a software idea before you build too much

Define the riskiest assumption

Every software idea rests on a stack of assumptions: that the problem exists, that it matters enough, that the people who have it can be reached, that your approach actually helps, and that someone will pay for it or keep using it. Some of these are safe bets. One or two usually are not.

The riskiest assumption is the one that, if wrong, makes everything else irrelevant — and that you currently have the least evidence for. Write your assumptions down and pick that one. It is what your first test should be about.

A common mistake is to test the assumption that is easiest to test instead. Checking that people like the design is easy and pleasant. Checking that they have the problem often enough to change their routine is harder, and much more important.

Decide what evidence would change your mind

Before you run a test, decide what result would make you stop, change direction or carry on. If you skip this, almost any result can be read as encouraging.

It doesn’t need to be precise. Something like “if fewer than a handful of the people I talk to describe this problem without prompting, I’ll rethink who it’s for” is enough. The point is to commit before you see the answer.

Test the problem before the solution

If your riskiest assumption is about the problem, you don’t need a product to test it. Conversations, observation and a look at what people currently do will tell you far more, far faster. The guide on finding problems worth solving covers how to do this well.

Only once you are confident the problem is real and frequent is it worth testing whether your particular solution helps.

Use a prototype, mock-up or manual service where possible

Many solutions can be tested before they are built. Options include:

• A clickable mock-up, to see whether people understand what the product does and how they’d use it.
• A landing page describing the product, to see whether the description makes sense and whether people ask for more.
• A manual service, where you do by hand what the software would eventually automate, to see whether the outcome is valued.
• A demonstration of the core idea, without accounts, settings or edge cases.

Each of these trades realism for speed. That’s fine at this stage: you are trying to learn whether the idea is worth building, not to prove that it scales.

Build the smallest useful product

At some point a mock-up isn’t enough. Some things can only be learned when people use a real product, in their own time, for their own reasons. When you reach that point, build the smallest useful version — small enough to build quickly, but complete enough that someone could genuinely get value from it.

“Useful” is the important word. A product that is too small to be useful will fail the test for the wrong reasons, and you won’t know whether the idea or the execution was at fault.

Put it in front of real people

Friends and family are a reasonable first audience for checking that something works, but they are a poor audience for testing whether it is valuable. They want to be supportive, and they may not have the problem.

Aim for people who have the problem you set out to solve and no particular reason to be kind to you. The guide on getting the first users for a new software product covers where to find them.

Observe behaviour, not just compliments

“That’s a great idea” is not evidence. People are generous with praise and much more cautious with their time, money and attention. Watch what they do:

• Do they complete the main task without help?
• Where do they hesitate, get stuck or give up?
• Do they use it again without being reminded?
• Do they mention it to anyone else?

If you can, watch someone use the product for the first time without explaining it. It is uncomfortable and extremely informative.

Measure return use and willingness to act

The strongest early signals are that people come back, and that they are willing to do something that costs them: sign up, invite someone, book a call, join a pilot or pay. A small number of people doing these things is worth more than a large number saying nice things.

Keep the measures simple. At this stage you are looking for a clear signal, not a dashboard.

Decide: improve, change, pause or stop

At the end of a test, compare what happened with the evidence you decided would change your mind. Then make a decision. There are usually four sensible options:

• Improve— the idea is working and the problems are fixable.
• Change— something is working, but for a different person, problem or use than expected.
• Pause— the evidence is unclear, and other work is more promising for now.
• Stop— the riskiest assumption turned out to be wrong.

Stopping is not failure. It is the test doing its job, and it frees up time for a better idea.

Keep a record of what you learned

Write down each test: the assumption, what you did, what you expected, what happened and what you decided. It takes a few minutes and pays off quickly. It stops you re-testing things you already know, and it makes patterns visible across ideas.

How Incyworks tests ideas

Each Incyworks product lists what is currently being tested, because the test shapes what gets built next. For example:

• Daily View is testing how much information is useful on a daily display before clarity becomes clutter, and is recruiting a small group of pilot users in and around Bath to find out.
• Role CV is a live beta testing whether a role-first assessment helps people focus on better-fitting opportunities, including whether they come back to assess further roles.
• Conxy, a puzzle game, is testing whether its move-count mechanic creates enough challenge and replay value, by watching completion, replay and abandonment on a small set of levels.

All three follow the same principle: