Check Message
The first question to turn an idea into an app shouldn’t be “What should I build?” but rather “Whose problem am I trying to solve, and what is it?” In vibe coding, AI generates screens and code blazingly fast. That is precisely why it’s more dangerous—because even when the problem is blurry, a plausible-looking app gets created far too quickly. An idea can start with a flash of inspiration, but an app must start with problem definition.
Characters
Mason: A novice developer getting comfortable with vibe coding. Now, he harbors the ambition: “I want to build an app myself.”
Sophia: A 10-year veteran developer. She believes problem definition comes before ideas and warns against the habit of blindly requesting code from AI right away.
Daniel: A project manager with a planning background. He is adept at breaking ideas down into user problems, usage flows, and verifiable value.
Q. To Turn an Idea into a Real App, What Should the First Question Be in vibe coding?
As soon as Mason opened his laptop, he spoke up.
“I just got an app idea!”
Daniel asked welcomingly, “Sounds great! What kind of app is it?”
“Well… an app where people can log their reading. It’s a reading tracker app, but AI organizes book reviews, recommends read books, lets you share with friends, sets up polls, gives out badges…”
Sophia quietly raised her hand. “Hold on, Mason. I need to slam the brakes on you right now.”
Mason paused. “Why? Isn’t it better the richer the ideas are?”
Daniel said with a laugh, “Having rich ideas is great, but right now your reading tracker app has a space station, a bookstore, a book club, social media, and a game arcade all mixed together at once.”
Mason felt a bit wronged. “Then where should I start? Can’t I just ask the AI, ‘Build me a reading tracker app’?”
Sophia answered, “You can build it. But if you start like that, the AI will build something that merely looks like a reading tracker app. The problem is, no one knows who needs it or why.”
“Aren’t features what matter most in an app?”
“A problem must exist before features. An app is a tool to solve a problem, not a brag about technology.”
Daniel turned Mason’s laptop slightly toward himself. “Let’s reframe the first question.”
Mason asked, “How?”
Daniel threw out a phrase: “Instead of asking ‘What app should I build?’, you must ask: ‘Whose problem am I trying to solve, and what is it?’“
Mason stared at that sentence. “Whose problem, and what is it…”
Sophia nodded. “That’s the first question. The moment you turn an idea into an app, you must look at the user before the technology. Before making AI write code, we need to know what problem we are trying to solve.”
An Idea Is Not an App
When an idea pops up, ordinary people immediately imagine an app:
- “I want to make a workout tracker app.”
- “I want to make a restaurant recommendation app.”
- “I want to make an app that helps with meetings.”
- “I want to make a meal logging app.”
- “I want to make an AI English conversation app.”
These phrases are fine as starting points, but they are not yet enough to “build an app.” That’s because most of them are closer to the “shape of a solution.” The problem to be solved remains unclear.
Even for a workout tracker app, there are many types of users:
- Someone who just started working out for the first time.
- Someone trying to manage routines at the gym.
- Someone who wants to compare running logs.
- Someone who wants to lose weight consistently.
- Someone trying to manage bodybuilding or weightlifting history.
They all share the words “workout log,” but their actual problems are different. Beginners don’t know what to do. Routine managers want to record quickly. Runners want analysis on terrain and pace. Dieters care about not giving up. Bodybuilders need to see multiple people’s records at a glance.
Even with the exact same idea, if the user changes, the app changes completely.
Mason asked, “Then a ‘reading tracker app’ would also change depending on the user?”
Daniel said, “Of course. It changes completely depending on whether it’s for someone who just started reading, organizing logs for a heavy reader, a shared app for a book club, or an app where parents manage books read by their kids.”
Sophia added, “If you say ‘reading tracker app,’ AI will build a generic form: Enter book title, enter author, star rating, memo, submit. Looks plausible, right? But whether that actually solves a problem is another story.”
Ideas can be flashy, but an app isn’t built on flashiness alone. An app exists to relieve a specific pain point for a specific user in a specific situation. So the first question is always just one: Whose problem does this app solve, and what is it?
The First Question Is Not for the AI—It’s for Myself
Mason placed his hands back on the keyboard. “Then I should ask the AI like this: ‘Whose problem should a reading tracker app solve, and what should it be?'”
Sophia laughed. “That’s good too, but you have to decide first.”
“Me?”
“Yes. There’s a common misconception in vibe coding: tossing every question to the AI first. But there are certain inputs you must decide before hearing from the AI.”
Daniel added, “AI excels at pulling up candidate options. But it cannot decide on your behalf what problems you are interested in, which users you understand best, or what you truly want to build.”
AI can suggest many possibilities:
- “A reading tracker app could help busy office workers not forget book contents.”
- “It could be an app for book club leaders to share member reviews.”
- “It could be an app for parents to manage their children’s reading habits.”
- “It could be an app for students creating document notes for exam prep.”
These suggestions are helpful, but the choice belongs to the human.
Mason said, “So rather than deciding ideas on my behalf, AI is closer to a starting point to organize my thoughts.”
“Right. AI can lay out a generic map, but you must decide which path to take.”
Daniel asked, “It’s especially great to start with a problem you’ve experienced yourself or one faced by someone close to you. That makes it easier to imagine the user and constrain features.”
Mason thought for a moment. “Then instead of making a reading tracker app for everyone, I could narrow it down to an app for someone like me.”
Sophia asked, “What kind of person is ‘someone like you’?”
“I read books, but as time passes, I easily forget what was in them. I underline sentences, but I never look back at them. When I try to write a full review, it feels burdensome, so I end up writing nothing.”
Daniel immediately caught on. “Great. Now the problem is starting to show.”
A Good First Question Narrows the User
- ❌ “I want to build a reading tracker app.”
- ⭕ “A reading memo app for office workers who easily forget book content shortly after reading.”
Narrowing an abstract idea down to a specific user makes it easier to immerse yourself. Broad ideas lose sight of the user and become difficult to solve in reality. When you don’t know who the app is for, apps targeted at the general public all end up looking identical. Conversely, narrowing the user makes decisions easy:
- For heavy readers/experts: Tags, citation management, and search features might be crucial.
- For users wanting to run a book club: Polls and notifications might be crucial.
- For users leaving 1-line reviews & ratings: Categories and comments might be crucial.
- For office workers who forget book content: Short summaries and revisit features might be crucial.
Mason said, “When you narrow the user, the features get narrowed down too.”
Daniel said, “Exactly. Good planning isn’t endlessly swelling functionality; it’s also about erasing what doesn’t need to be built right now.”
Sophia chimed in, “This is especially critical in vibe coding. AI is extremely good at adding features. If you just say ‘reading tracker app,’ it will attach book recommendations, social sharing, stats, badges, notifications, and AI summaries in a long row.”
Mason laughed. “That’s what I said earlier…”
“Yup. But if everything is attached from the beginning, the app gets bloated and hard to fix. Narrowing the user allows you to demand things from the AI more accurately.”
Problems Must Be Expressed as Scenes
Sophia asked, “Mason, can you express the problem you mentioned as a scene?”
“A scene?”
“Yes. When, where, and why the user feels uncomfortable.”
Mason pondered for a moment. “Hmm… An office worker reads a book on the subway on their way home from work. They find a great sentence and underline it. But later when they try to find it, they can’t remember which book or page it was in. When they look for reading memo apps, writing long book reviews feels burdensome. In the end, they don’t record anything.”
Daniel clapped lightly. “Awesome! Now that is completely concrete.”
Sophia nodded too. “That’s it. Problems must be expressed through scenes rather than abstract words.”
“Why?”
“Because only with a scene can you see what the app actually needs to do.”
Three clues emerge from the “commute subway” scene: The user is busy. They are more likely to use it one-handed rather than on a heavy, large screen. They feel burdened by long writing. They want to leave records quickly. They want to find them easily later. Rather than completely forgetting book contents, keeping memorable highlights in mind is what matters.
These clues become the blueprint of the app:
- Short memos might matter more than long essay features.
- Fast saving might matter more than complex categorization.
- A structure good for revisiting later might matter more than registering books.
- AI summary features might be more appropriate as “tagging key keywords in short memos” rather than “generating long book reviews.”
Daniel said, “When you express a problem as a scene, features follow naturally.”
Sophia added, “Right. Conversely, without a scene, features become floating narratives: ‘This tech is cool, that tech is flashy, this is trending nowadays.’ Before you know it, the app inflates.”
Mason wrote in his notebook:
- Ideas start as nouns, but problems reveal themselves as scenes.
- You must deliver problem definitions to the AI, not just ideas.
Mason opened the AI chat window again. “So what should I say to the AI now?”
Daniel said, “This time, instead of ‘Build me a reading tracker app,’ try expressing the problem we just defined.”
Mason typed slowly:
“I want to build a small app for office workers who easily forget memorable contents after reading a book. Users easily discover great sentences one-handed during their commute or brief moments, but feel burdened by writing long reviews. Therefore, I want to build an app where they can quickly save only the book title, memorable sentences, and short memos, and look back at them later. For now, I plan to build a prototype to validate the idea, not an actual production service. Please summarize the core user objective and the smallest starting scope for this app.”
The AI began generating a response.
Mason looked at the screen and said, “It definitely answers differently. It doesn’t just pile up technologies; it organizes the core purpose and starting scope.”
Sophia said, “That’s the difference. Give the AI an idea, and it imagines a generic app. Give it a problem definition, and it starts imagining an app fitted to that problem.”
In vibe coding, the first thing to deliver to the AI is not a flashy feature list. It is the definition of the user. A good problem definition usually includes four things:
- Who uses it?
- In what situation do they use it?
- What is the pain point?
- How do they want to reduce that pain point first?
With these four, the AI’s responses become significantly more specific. You don’t even need to write code yet. In fact, it’s better to ask these questions before writing code:
- What is the smallest core feature to solve this problem?
- What is the most important activity in this situation?
- What features do NOT need to be built right now?
- What should be left for the user after using this app?
These questions set the direction of the app. And once the direction is set, you can pick the features. Only when the first question is solid can the AI become a great collaborator.
Mason smiled as he watched the AI’s answer. “It’s true that AI is smart, but the answer changes completely depending on what I feed it.”
Sophia said, “Right. AI thinks along the shape of the problem you give it. Give it a blurry problem, and it builds a blurry app; give it a sharp problem, and the chances of it building a sharp app skyrocket.”
Daniel added, “Using AI in the idea stage is great, but calling it straight to implementation is a no-go. At first, you should utilize it as a sounding board.”
“Great expression. Don’t say ‘Build it’ to the AI from the start. Say ‘Organize this,’ ‘Narrow this down,’ ‘Assume this,’ or ‘Find opinions on this.'”
Mason asked, “Then can I summarize the first question like this? ‘Whose problem does this idea solve, and what is it?’“
Sophia nodded. “That’s the core. And if possible, you should be able to state it in a single sentence.”
Mason wrote down his app in one sentence:
An app that helps office workers who easily forget memorable contents after reading easily leave short memos without burden and look back at them.
Daniel smiled. “Now I can see the app’s name.”
Sophia also said, “Yup. Now we’re finally ready to talk about the feature list with the AI.”
Mason laughed. “I haven’t written a single line of code yet, though?”
“That’s why it’s great. Because you set the path before writing code.”
Chapter 15 Summary
- The first question to turn an idea into a real app is not “What should I build?” but “Whose problem am I trying to solve, and what is it?”
- In vibe coding, AI generates code blazingly fast. However, jumping in hastily without design yields an app with a warped direction. Therefore, you must narrow down the user before implementation and concretely express realistic scenes experienced by the user.
- A good problem definition includes four elements: [Who, In what situation, What pain point, How to relieve it].
- If you can answer this question, AI ceases to be a simple code generator and becomes a true partner transforming ideas into apps.