In the previous chapter we confirmed that indie development moves through the five phases of "decide → prepare → build → ship → grow," and that the iron rule is "narrow to one feature and launch an MVP." This Chapter 2 covers that first phase, "decide." Let's work through it together, all the way from deciding what to build and for whom, in small scope, to shaping it into a spec.
Get "what you want to build" into a form you can hand to AI
Why "decide" comes first
The urge to start coding right away is understandable. But the most common failure in indie development is "losing track of what you're building while you build it." Move your hands with a vague goal, and midway you drift, "oh, this feature too," and it never gets finished.
That's why coding can wait. First, make it clear "what, for whom, and how far to build." Set off without a map or a destination and getting lost is inevitable; but once the destination is set, AI as your partner can guide you along the shortest route.
Features pile up and it gets complex. Your instructions to AI wander every time. The finish line recedes, motivation runs dry, and it's abandoned.
The goal settles on one thing. You can instruct AI precisely, and the output stays on track. You reach "something that works" by the shortest path.
💡 "Deciding" is not time spent agonizing. You don't need a perfect plan. What you do in this chapter is a small decision that fits on a single sheet of paper (or one note screen). Deciding, even tentatively, and moving forward gets you to the goal far faster than stalling in worry.
Finding an idea — bounce it off AI
"I don't have anything I particularly want to build." That's fine. Ideas aren't wrung out of thin air; they're picked up from everyday inconveniences. And that digging is exactly what AI does best. No need to groan over it alone. Make AI your sounding board, and ideas start bubbling up.
The little things that feel like a chore every day. Repetitive manual work, the effort of recording things, time spent searching. What troubles you troubles someone else too.
Something you thought "I'd use an app like this if it existed." Your first user is you. When you genuinely want it, the motivation to build lasts.
Throw a vague interest at AI and let it ask you questions back. The outline emerges as you talk. It's the perfect partner for thinking out loud.
The knack for bouncing ideas is throwing a concrete prompt. "Got any good app ideas?" won't get you good answers. Instead, narrow the angle and ask like this:
- "Give me 10 app ideas that solve the hassle of managing household finances, one line each."
- "Of those, which is the smallest to build? Add your reasoning."
- "Would anyone actually use this one? Tell me the target user and the situation where they'd use it."
- "Do similar services already exist? If so, where's the gap an individual can target?"
- "If I cut this down to just one feature, which feature should stay?"
Having it produce 10 and picking 1 works well. AI lines up a large batch of candidates in an instant, so your job is to focus on choosing. When something clicks, dig into it further.
Narrow to one feature — the iron rule
Once an idea comes into view, the next thing that matters is "don't overload it." Remember the iron rule from the previous chapter? Narrow to one feature and launch an MVP — this is the rule most often broken in indie development, and the one most worth keeping.
The moment you get greedy, "since I'm building it anyway, that feature and this one too," the finish recedes. Two features isn't twice the work; because of the combinations, it swells to three or four times. A single person's time and energy are limited. At first, cut all the way down to just one "if it does this, it has value."
Register books, review notes, star ratings, reading-time graphs, sharing with friends, AI book recommendations, barcode scanning… Aiming for everything, it never gets finished.
Just "log a book you read with a one-line impression." Being able to look back over a list is enough. Launch first; add more once it's used.
✅ The test for cutting: "does it fall apart without this?" Put any feature you're unsure about into the "later" box first. Don't discard it; add it after launch if it's truly needed. Once the first feature works and someone uses it, the users' reactions will tell you what to add next.
Put your idea into one line
Next, turn that one narrowed feature into a single line of words. This is the heart of the chapter. Fit the fuzzy image in your head into the form "for whom, which pain, solved how," and the idea snaps into focus.
"An app for people who read a lot that solves the trouble of forgetting the books you've read by letting you quickly log a one-line impression and look back over them in a list."
If you can write this one line, your indie project is halfway to success. Everything after it — choosing tech, instructing AI, even the pitch when you launch — hangs on this line as your unwavering axis. When you can't write it well, let AI help here too. Ask "turn this feature into one line of for-whom, which-pain, solved-how," and it will offer several drafts.
Turn it into a spec — the foundation of AI development
Once the one line is set, finally turn it into a spec. A spec is "a design memo of what to build." Don't overthink it; just writing out the three points of screens, data, and actions minimally is plenty.
Why does the spec matter? Because in AI coding, the spec becomes the foundation itself. Rather than dumping "build an app like this," handing over a spec that lays out screens, data, and actions makes AI return code that's many times more accurate. The approach that takes this to its logical end is spec-driven development, and the same principle works for indie projects.
What screens do you need?
e.g., a log list, adding a log. 2–3 screens is enough in most cases.
What do you save?
e.g., book title, impression, log date. Just list the fields as bullets.
What can the user do?
e.g., add a log, view the list. List what they can do as verbs.
Writing out these three is your first spec. For a reading-log app, for instance, the memo would look like this:
Data: book title (text) / impression (one-line text) / log date (date)
Actions: add a log, view the list newest-first, delete a log
💡 The spec doesn't have to be perfect. You don't need to write it all out from the start. When you notice while building, "ah, I need this too," just add it. What matters is "having one sheet as a foundation to start from." Working from a draft lets both AI and humans move many times faster than starting from a blank page.
How to proceed on the beginner and hands-on routes
The "decide" work up to here is the same on either route. What differs is only how formally you write the spec and who you hand it to. Proceed in the way that fits your route.
Writing the spec by hand in a notepad or notebook is fine. No polished document needed. Once you've bulleted "screens, data, actions," paste it straight into an AI chat and bounce it around. Ask "any gaps or contradictions in this spec?" and AI fills the holes.
Chapter goal: the one-line and the three-point memo written — that's enough.
Gather the spec into a Markdown file (e.g., spec.md) and hand it to Claude Code or Cursor. An AI editor reads the spec and uses it as the foundation for implementation, so the more careful it is here, the faster things go later. For how to write it, spec-driven development is a good reference.
Chapter goal: one spec.md ready to hand to your AI editor — that's enough.
On either route, by the time you finish this chapter, you have "the one-line" and "the minimal spec of screens, data, and actions" in hand — that's the goal. Get this far and all that's left is setting up the foundation to build. You're ready to move to the next phase.
Summary and next chapter
- Coding can wait. First, decide "what, and for whom, to build" so you don't get lost.
- Ideas come from everyday hassles and what you want. Bounce them off AI to get 10, then pick 1.
- The iron rule of indie development is "narrow to one feature." Put uncertain features in the "later" box.
- Put the idea into one line of "for whom, which pain, solved how."
- The spec is the minimal three points of screens, data, actions. In AI coding, the spec becomes the foundation.
- Beginners go with a notebook and AI chat; hands-on with a Markdown spec.md.
That's the "decide" phase. With your idea in one line and a minimal spec in hand, you're one step short of starting to build. Next is the phase where you decide which tech and tools to actually build it with. You can go back to Chapter 1, "The big picture and choosing your route," to review the map, or move straight on to Chapter 3, "Prepare your tech and tools." The work of turning your one line into something real begins.