App idea? Three questions to ask before you build with AI

One of the most familiar moments in vibe coding: you have an idea for an app nobody has built yet, you describe it to Claude Code, hit enter, and a few minutes later something that looks like a product appears on screen. A dashboard, three cards, a huge headline, a nice gradient.

And that's the thing. When we ask an AI to build something new, it doesn't start from zero. It looks for what it already knows and assembles something that fits our request. If dozens of similar products already exist, this usually works great. But if the idea is truly new, there's a problem: the model doesn't have much to copy, compare against or lean on, and it may hand us back the existing thing that's closest to what we asked for.

In other words: the more familiar the idea, the faster AI can build it. The newer the idea, the more you need to understand it before you start building.

And I found this out the hard way.

A three-month plan for an app with nothing new in it

In mid-September I started planning a system for managing my workshops and courses. Nothing groundbreaking. Quite the opposite. The system was supposed to include tickets for each session date, a payment page, a registrant list and a course management module.

Still, I approached it as if I were developing an innovative product. The result was a long spec and a work plan of about five months. After a little over a week I stopped and looked again at what I was trying to build. I realized something pretty embarrassing: there was nothing here to discover.

Hundreds of products already do these things. So I threw out the spec and told Claude: date, name, price, number of seats and description. That's it. By the end of that day, the first module was already running in a test environment.

A long spec became four fields.

The problem wasn't that AI built the wrong thing. The problem was that I did discovery work where there was no discovery to do. I was trying to reinvent something that had already been solved.

So how do you know whether an idea needs discovery?

I look for the "not yet." Not the part that makes the product cool, but the part that doesn't have a clear answer yet.

Almost no product is entirely new. Even the newest product in the world needs signup, payment, settings, tables, search and buttons. There's no reason to spend months figuring out how to build those. So I separate two things: what's already known, you assemble. What isn't known yet, you research.

And that's especially true now, when AI has made assembly cheap and fast.

Three questions to ask before you start building

1. For whom?

Is there already a good product for the people this idea is meant for? It's not enough to ask whether a product does exactly the same thing. Those people might be using Excel, WhatsApp, Notion, or a mix of several tools today.

The check: ask Claude to find the three products closest to your idea, and check what those people use today. If there's already a good solution, there's probably not much to discover here.

2. What?

Is the problem the idea is meant to solve already known? Are people already talking about it, does it already have a name, and do solutions already exist that answer it?

The check: search Google and the communities where these people hang out, and use their words, not the words we invented to describe the idea. If people are already describing the problem and looking for solutions, we're probably not in unfamiliar territory.

3. How?

Can you explain how the product works using patterns everyone already knows? A dashboard, a table, a calendar, a chat, a list or a form.

The check: try to explain to someone how the screen works, without drawing it. If you can explain it easily with things that already exist, there's probably not much new here. If you can't, this is where it gets interesting.

The diagram has one more layer: the higher a dot sits above the line, the more there is to discover in its question.

The "not yet" is not proof of innovation

It's important to be precise here. If we didn't find a similar product, problem or interface, it doesn't mean we spotted something new. It only means we found something we don't understand yet.

Maybe there's no solution because nobody thought of it. Or maybe nobody thought of it because nobody needs it. So the default should be "yes": first you look for what already exists, and only when you find no answer do you mark "not yet."

And then you move from searching to real discovery. Because search can show us what already exists. Only people can help us understand what's missing.

So what do you do with each kind of idea?

My split is simple: a commodity idea needs speed. An innovative idea needs a map and speed.

Commodity

If all three questions got an answer, there's no reason to linger. Say you want to build an appointment system for a veterinary clinic. The clinic is closed on Thursdays, wants certain fields on every appointment, one color for cats and another for dogs. It's a custom product, but it's still a commodity.

There's no new problem to understand here. Claude Code can build this fast, and if a product already exists that does it well enough, maybe you don't need to build at all.

Where to start: Claude Code or an existing product.

What it costs: much less than it used to. Things that once took a development agency, a big budget and months of development can now be assembled quickly with AI.

Innovative

Here at least one of the questions is still open. Maybe there's an audience no product serves well, maybe there's a problem people experience that has no solution yet, and maybe there's a completely new way to do a familiar action.

Here you don't start with a prompt. You start with people. One conversation with someone who lives with the problem can teach us more than ten reworded prompts to Claude.

And it costs more too. Not necessarily in money, but in time. You have to find people, talk to them, understand what they do today, what frustrates them and what they've already tried. But there's an important advantage: we don't have to research the whole product. Only the part that isn't clear yet.

When there's no map, you have to draw one

This is the part where discovery really matters. First you talk to people. AI can help us prepare for the conversations, find patterns and summarize what we heard, but it can't replace the person who lives with the problem.

There's a difference between information and truth. AI knows a lot about what's already been said. The user can tell us what hasn't been said yet. Synthetic users can help too, but remember their limit. They're usually too nice, and they're not the ones who pull out a credit card.

After talking to people, you map the problems. Here AI can help a lot: sorting, grouping and finding patterns in everything we heard. Then you choose where to focus.

Only now do you start designing. Instead of writing code, you can have agents produce several directions in parallel: a product agent, a UX agent and a development agent. Three directions, side by side. You look, you talk, you move things around, add sticky notes, ask for another variation and choose.

A sticky note on a screen is the cheapest fix there is. The code comes later.

So what do you do tomorrow morning?

Take the thing you're planning to build and run it through the three questions: for whom, what and how.

If you got a "yes" on everything, you probably have a commodity product. If it's an internal tool, just build it. If it's a product you want to sell, ask one more question: if anyone can build the same thing in a weekend with Claude, where will our advantage come from?

If you got a "not yet" on any question, don't rush to code. Stop there. If it's "for whom" or "what," this week, talk to a real person who lives with the problem. If it's "how," build three mockups of the same screen and test them side by side.

Everything else you can assemble later. And fast.

A commodity idea needs speed. An innovative idea needs a map.

And in the age of AI, an innovative idea needs both: speed for everything that already exists, and a map only where there's still no answer.

Claude Code already gives us the speed.

We still have to learn to draw the map.