# Your project > The capstone of the Vibe coding track. Bring the patterns together on something real, with version control and the principles you have learned _60 min · intermediate · track: vibe-coding · id: vibe-coding-project_ > **Team:** > > This is the end of the Vibe coding track and the point where the work > stops being practice. You have the tools ([Claude Code](/course/claude-code), > [version control](/course/version-control)), the > [patterns](/course/vibe-coding-patterns), and the > [principles](/course/principles). Now you pick something you actually want to > exist, and you build it. The earlier courses had try-its and a structured [Build a game](/course/build-a-game) exercise, all with the safety rails of "this is throwaway." This one drops those rails. Pick something you want to use, or that someone on your team would use, and ship a first version end to end. ## What "project" means here **Something you build for yourself, that runs on your own machine.** Not a SaaS, not a thing you ship to a customer, not even an app with a link you can DM to a friend. This course stops short of deployment on purpose. The bar for an app other people use is much higher (auth, error handling, monitoring, security review, on-call when it breaks) than the bar for one only you use. Vibe coding is genuinely excellent at the personal-tool end of that spectrum, and a different discipline at the production end. The production end is what the Agentic engineering track at Level 4 will eventually cover. > **Warning:** > > You will not be able to share a public link to what you build here, and that > is the point. Deploying a vibe-coded app safely is a research project of its > own, and a worthwhile one if you want to take it on later. For this course, > keep your project local: a web page you open from your own browser, a CLI > you run from your terminal, a small desktop tool. The restriction makes you > go faster, not slower. Three rules of thumb for the project itself: - **You actually want it to exist.** Not just an exercise prompt. - **It runs locally.** Nothing the public internet has to reach. - **It has a clear "done" state for the first version**, even if you keep building afterwards. If you cannot describe it in two sentences, it is too big. Cut it down. Shapes that work well as personal tools: - A small app that pulls from your Strava (or Strava plus Oura, plus your calendar) and tells you something useful about your last month. - An invoice creator: type the line items in a simple form, get a clean PDF out the other side. - A puzzle, a single-player game, or a more elaborate version of what you built in [Build a game](/course/build-a-game). - A "show me what I did" page built from your own git history. - A single-page tool that automates one annoying task you do every week. If your idea needs other people to log in, sign up, or share state with each other, set it aside for a later level. Pick something else for now. ## How to run it **Use everything you already learned. Resist the urge to skip the boring parts.** 1. **Plan it.** Open Claude Code in an empty folder. Press `Shift+Tab` twice to enter plan mode. Describe what you want in two paragraphs: what it does, what "done" looks like for the first version. Read the plan the agent drafts. Strike the assumptions you do not like. Approve. This is the [start-with-a-plan principle](/course/principles) made concrete on something that matters. 2. **Snapshot before the agent builds.** Tell Claude Code: "Set up version control here and take the first snapshot." This is the cheapest insurance there is. From now on, every step the agent takes is reversible. The [version control](/course/version-control) habit pays off most on the projects you actually keep. 3. **Build the first version in one go.** Hand the plan over and let the agent run. Don't course-correct until it stops. If it asks questions, answer them; if it makes assumptions, let it. This is the one-shot pattern from [Vibe coding patterns](/course/vibe-coding-patterns) at the project scale. You will be surprised how much of it is right. 4. **Snapshot the first version. Then iterate.** Take a snapshot the moment the first version works at all. From here, alternate "make it better" rounds with snapshots. Read each diff before you approve. Each working state is somewhere you can come back to. 5. **Stop at "done enough", not "done."** The temptation at this point is to keep polishing. Resist it once you have something you would actually use. Take a final snapshot, push to a remote, and use the thing for a week before you decide what to add next. The [you are responsible](/course/ai-first-mindset) rule lands hardest here. This is your project now, not the agent's. 6. **Show it to one person.** Not a public link (you don't have one yet), but a screen-share, a screenshot, or the repo URL to someone who would care. Their reaction is feedback your future projects will inherit. ## What you should notice - **How the patterns combine.** One-shot got you the first version. Make-it-better closed the gap. Content + form was probably hiding inside the prompt you wrote without you naming it. - **How version control changes how brave you are.** With clean snapshots between every step, "let's try a wild idea" costs nothing. Without them, every change is a small worry. - **Where the agent surprised you.** The choices it made that you would not have made yourself. Some are better than your defaults; some are worse. Both are useful to notice. ## Reflect - What is the next version of the thing you just built? Write the one-line plan for it now while the project is still warm. - Which of the three patterns did the most work in this project? Which one will you reach for first on the next project? Once you mark this course complete, the Vibe coding track is done and you can claim the track certificate.