What should you do before you start building an app with AI?

AI tools make building fast, and that is the trap. When an app takes a weekend instead of a few months, it is tempting to skip the question of whether anyone wants it and let the launch answer it. But a launch to silence doesn’t tell you much: you can’t tell whether nobody saw it or nobody wanted it. A few days spent on this chapter gives you something better to build from: the problem in the words of the people who have it, a short list of them, and a result you decided on in advance.

This chapter is the same for both paths in the guide. You don’t need any tool yet, only a document to write in.

Step 1: Write the problem in one sentence

Before the product, write the problem. One sentence, in this shape:

[Who] struggle to [do what] because [why].

For example: “Freelance translators struggle to chase late invoices because every client pays through a different system.” That sentence names a person you could find, a task they do, and a reason it is hard. Compare it with “a smarter invoicing app”: that names a product, and nobody can tell you whether they have that problem.

Two checks on your sentence:

• Could a stranger say “that’s me” or “that’s not me”? If the “who” is “everyone” or “small businesses”, narrow it until they could.
• Does it mention your solution? If it does, take it out. The solution comes later and may change after step 3.

If you have two or three ideas, write a sentence for each. The one you can find people for in step 2 is often the one to start with.

Step 2: Find where those people already talk

People with a real problem are usually already talking about it somewhere: complaining, asking for advice, comparing tools. Your job is to find those places before you build anything.

Places to look:

• Forums and communities for that job or hobby, including subreddits, Discord and Slack groups, and Facebook groups.
• Question sites and search results. Search for the problem the way they would say it, not the way you would pitch it.
• Reviews of the tools they use today. Complaints in reviews are problems stated by people who already pay for something.
• Your own contacts. A former colleague who does the job is a good first conversation.

As you read, copy their exact phrases into your document. “I spend Sunday night chasing invoices” is worth more than anything you would write yourself, and you will use it on your page in step 4.

If you can’t find anywhere these people gather, write that down too. It means the idea may be fine, but reaching people will be the hard part, and that changes how you launch (chapter 8).

Step 3: Talk to a few of them

Reading gets you words. Talking gets you the details: what they do today, how often, and what it costs them. Paul Graham’s advice to founders applies before you build as well as after: “You can’t wait for users to come to you. You have to go out and get them.” (Do Things that Don’t Scale)

Send a short, honest message to people you found in step 2: you are looking into this problem and would like to hear how they handle it, in a short call or a few messages. Don’t pitch an app.

When you talk:

• Ask about the last time it happened. “Tell me about the last time you chased an invoice” gets a real story. “Would you use an app that…” gets a polite yes.
• Ask what they do about it now. A spreadsheet, a paid tool, a workaround, or nothing. Nothing can mean it doesn’t hurt enough.
• Ask what it costs them: time, money, stress, lost clients.
• Write down their words, especially the ones that sound annoyed.
• Ask if you can come back to them when you have something to show. The ones who say yes are your first users.

After a handful of conversations, go back to your sentence from step 1 and rewrite it if they described the problem differently. Asking people for money or a firm commitment is the stronger test; it has its own page: how to know if people will pay before you build.

Step 4: Put up one page with one promise and an email field

Now test the promise on people who don’t know you. Make one page with:

• A headline that states the result, in the words from steps 2 and 3. For example: “Get paid on time without chasing clients.”
• One or two lines about who it is for and how it works.
• An email field and a button such as “Tell me when it’s ready”.
• A price, if you have one in mind. A signup next to a price means more than a signup next to nothing.

Leave out the feature list, the screenshots of an app that doesn’t exist, and the countdown. One promise is enough, and it is what you are testing.

Any tool that shows a page and collects an email works: a form service, a site builder, or the AI builder you will use in chapter 2. If you want it hosted for you, Nordva Launch has a waitlist page with no code, free up to 100 signups per project, and it records where each signup came from. Not sure a waitlist is the right shape for your idea? Do you need a waitlist covers when to skip it. Get signups before you build goes further into getting the page in front of people.

Then share it in the places from step 2, where the rules allow, and send it to the people you talked to. Add a tag to each link you share (such as ?utm_source=reddit), so you can tell later which place sent the signups. UTM parameters explains the tags, and chapter 7 sets them up properly.

Step 5: Decide what number means “go”

Write this down before you share the page, not after. Once the results are in, it is too easy to decide that whatever happened is good enough.

Write three lines:

• Go: the result that means you build. For example, a made-up target: “20 signups from people who match my sentence, and 3 who agree to try an early version, within two weeks.”
• Change: the result that means you rewrite the promise or pick a different group, and test again.
• Stop: the result that means you move on to another idea.

Pick numbers that fit how many people you can reach. There is no standard figure that proves demand; the point is that you chose yours in advance. Count signups from the people in your sentence, not your friends. The replies, the people who ask when it’s ready and the ones who agree to a call count for more than the total.

What you carry into chapter 2

When this chapter is done you have:

• the problem in one sentence, rewritten after the conversations;
• a list of people who said you could come back to them;
• a page, a list of signups, and a note of where each one came from;
• the result you set in step 5, and what it said.

If it said “go”, the next step is choosing how to build: chapter 2, pick your tools. If it said “change”, change one thing and run step 4 again; it costs a page, not an app.

When to skip this chapter

If you are building a small tool for yourself and would build it anyway, skip the test: use it, then show it to a few people. And if you already have a site with a form that stores emails, you don’t need Launch’s page for step 4; the steps work the same with your own.