Now for Phase 3, "build." With the spec you decided in Chapter 2 and the tech and tools you chose in Chapter 3 in hand, you assemble something that actually works. Most people who stumble here don't actually do so because they "can't write code." They give up because they try to reach completion all at once. In this chapter, with AI as your partner, we guide you through a way of building that spins "make it small and run it" fast, on both the beginner and hands-on routes.
Aim not for "done all at once" but for "small steps forward"
The basic stance for building — cycle small
The most important stance in building is just one: repeat "build small, run it, fix it" fast. Don't try to build the finished form in your head in one shot; first build the smallest "working chunk," then grow it little by little.
Why does this work? Because a program only reveals what's wrong once you run it. Write 100 lines then run it all at once, and you're lost as to the cause. Write 10 lines and run it, and the mistake can only be in those 10 lines. It's exactly the same when you have AI write it: ask small and check immediately ends up being far faster and more reliable.
Dumping "build all the features at once" on AI. A pile of code comes out, but running it is a mess of errors. You can't find the cause and lose the will to fix it.
Ask one feature at a time: "just the screen that shows the list first." When it works, next, and stack them up. You move forward while always staying in a "working state."
⚠️ AI's code makes mistakes too — so always run it yourself. Code AI writes can look plausible yet error out when run, or behave differently from your intent. "It's AI-written, so it must be right" is forbidden. Always run the code that comes out with your own hands and check it with your own eyes. This is the first iron rule to build in indie development. Move on without running it, and mistakes pile up until they're unmanageable.
Steps of the "build, run, fix" loop
Turning this "cycle small" into concrete 4 steps gives the diagram below. Spin one feature's worth round and round through this loop. One lap is a few minutes to a few dozen minutes. The faster you cycle, the better you get.
Ask AI concretely for "just this one feature next." The narrower the scope, the higher the accuracy.
Run it the moment it comes out. Confirm the result with your own eyes in the browser or terminal.
If there's an error or something feels off, fix it by conversation: "change this to that." Repeat until it works.
When it works, save it as a checkpoint (commit). Keep the good state and move to the next feature.
💡 Don't take STEP 4 "save" lightly. If you save (a Git commit) each time a feature works, then even if the next change breaks it you can return to the last working state. It's a lifeline against the tragedy of "but it worked yesterday." We cover the concrete how-to of saving in detail in the next Chapter 5.
Implementation styles for the beginner and hands-on routes
"Cycle small" is the shared stance, but the concrete way of cycling changes by route. Confirm how to proceed for the route you chose in Chapter 1. Of course, you can mix or switch midway.
With vibe coding, assemble the app while conversing with AI. "Make a list screen" → "make the button blue" → "save it when pressed" — ask in plain words, look at the screen, ask again. This repetition is itself the "cycle small" loop.
Tip: ask for only one thing at a time. If it doesn't go well, just say "undo the last change."
Hand the whole spec to something like Claude Code and delegate a chunk of implementation. The key is to automate safely: adjust the effort to the workload, and use permission modes so it doesn't rewrite files more than intended.
Tip: delegate big, but confirm small. When stuck, find the fix in the error roundup.
On either route, what you must not forget is the basic stance of "run what comes out and check it yourself." Whether you build by conversation or have it built automatically, checking is the human's job. Not skipping this bit of effort is what separates reaching completion from not.
If you're embedding AI features
If what you're building is an "app that uses AI" — say, summarizing text, answering questions, or classifying images — you need a mechanism to call AI from within the app. This gets a little technical, but the options sort into three big buckets. Choosing only what your app needs is enough.
If you just use one AI model from your app, calling an AI API is the basic move. Think of it as a "window where you send text and AI's answer comes back."
To use several AIs by situation, unify them into one common way of writing with the Vercel AI SDK. For centralized management in operation, an LLM gateway is handy.
To have it answer based on your own documents or materials, use RAG. It's a mechanism that hands AI "materials just for you" to answer from, giving you originality.
🧭 If unsure, ① alone is fine. For a first MVP, just calling one AI API is enough in most cases. Add ② and ③ only once the need arises — "I want to compare multiple models," "I want it to answer from my own data." Here too, "build small" is the right answer.
How to move when you're stuck
While building, you'll get stuck somewhere without fail. An error appears, it doesn't behave as expected — this isn't failure, it's proof you're building. What matters is, when stuck, to not panic and to isolate things in order. Now that AI is here, you escape a snag far faster than before.
Copy the whole red text and ask "I got this error. What's the cause and the fix?" The error text is the biggest hint. Don't rewrite it your own way; paste it first.
Recall "how far was it working." The one spot you changed just before is the cause in most cases. Narrow the scope and you'll always find the cause.
If it gets tangled, return to the last working state you saved and redo. Backing off is often faster than chasing it down.
🔧 For those on the hands-on route. The common errors and fixes with Claude Code and the like are gathered in the error roundup. Agonizing over the same error is a waste of time. Make it a habit to look it up first when stuck, and if that fails, ask AI.
Chapter summary
The heart of Phase 3, "build," is less about technique and more about the stance of spinning "build small, run it, fix it" fast. Don't aim for completion all at once; grow a working chunk little by little.
- The basic stance is spinning "build small and run it → fix it" fast. Don't aim for completion all at once.
- AI's code makes mistakes too. Always run what comes out and check it yourself.
- 🌱 beginners go with vibe coding while conversing; 🔧 hands-on hand over a spec and automate safely with effort and permission modes.
- To embed AI, start from an API. For multiple models, Vercel AI SDK / LLM gateway; for your own data, RAG.
- When stuck: hand over the error text → isolate it small → return to a working state. Use the error roundup too.
Once you have something that works, next it's time to ship it to the world safely. You can go back to the previous Chapter 3, "Choose your tech and tools," to review the prep, but once implementation is cycling, move on to Chapter 5, "Test it and ship it," where you lock down testing and security and launch.