Skip to content

Questions · Published

I have an idea for an app. What should I do next?

TL;DR

Write down your best guesses about who it's for, what problem it solves for them, why they'd choose it and what they'd pay. Then go and find out: talk to five people who have the problem, put something rough in front of them and ask someone to pay. Let what they do shape what you build next.

It's tempting to open Lovable or Claude Code tonight and start building, and that's not a bad instinct. A rough version can teach you a lot. The risk is spending months building while learning nothing about who will pay for it. So build, but put what you build in front of real people as you go.

Here's a good way to start.

1. Write down your guesses

Every idea rests on a handful of guesses. Write down your best answer to each one:

  • Customer: who is this for, who needs it most, and how will you find them?
  • Problem: what are they struggling with, what do they do about it now, and what does it cost them?
  • Promise: what outcome are you offering, and why would they choose you over what they do now?
  • Solution: what's the smallest thing that would deliver that outcome?
  • Commercial: what will you charge, who pays, and does that cover what each customer costs you to serve?

Be specific. "Small businesses" is a guess you can't check. "Office managers at accountancy firms with five to 20 staff" is one you can. Together, these answers are your Business Hypothesis.

2. Choose what to find out first

You can't check everything at once, so pick the thing you most need to understand. A good place to start is the guess that's most likely to be wrong and would hurt most if it were. If you've worked in the industry and lived the problem, it's usually something other than the problem itself: whether people will pay, whether the person with the problem can sign off the spend, or whether you can reach enough of them.

3. Talk to five people who have the problem

Book five conversations with people who fit your customer. Start with people you know, then try a couple from outside your network, because that's closer to how selling will feel later.

Ask about what they've actually done. When did this last happen? What did you do about it? What did it cost you? People are kind, so "would you use this?" gets a yes that means very little. Their last bad week tells you far more. There's more on this in what to ask potential customers.

4. Put something real in front of them

Give people something to react to: a rough working version, a clickable prototype or a one-page website with your promise and a price. Each of these takes an afternoon now. If you can, sit with someone while they try it on their own work, and watch what they do.

5. Ask someone to pay

Asking for money tells you far more than asking whether they like the idea. You can sell the outcome before the software is finished and deliver it by hand at first. If someone pays, or signs a letter of intent saying they will, they've accepted your offer. Whether they get the outcome and keep paying is what you find out next.

Then make sense of it, and decide what's next

Results are rarely clean. Some people will be keen, some won't, and feedback will conflict. Look at what people did more than what they said, notice what surprised you, and decide whether to keep going, change something, look into it further or stop. Then go round again.

When what customers have done gives you a clear picture of who it's for and what it must do, and ideally someone has committed to pay, that's the time to invest in a proper first version. See what the first version should include.

None of this takes long. A week of conversations, a rough version and a page with a price can save you months of building the wrong thing.