Your first vibecoding project: a 12-step checklist before you open Cursor

Your first vibecoding project will start with the worst possible decision: you open Cursor and type “build me a SaaS app for task management”. Four hours later you have chaos in which no file will compile. Below, a 12-step checklist that turns the same idea into a shippable project in two days.

1. Pin down one user story

Not a feature, not a product. One user story in the “as X I want Y so that Z” format. Example: “as a project manager I want to see all my team's tasks on one board so I can tell if we will hit the deadline”. That is it. If you have more than one story, you are too early.

2. Pick a “boring” stack

A first project is not the place for exotic libraries. Recommended stack for the rookie vibecoder: Next.js 15 + App Router, TypeScript, Tailwind, shadcn/ui, Drizzle + Postgres (Neon), tRPC, Vercel. Every model knows this combo and there are thousands of public examples.

3. Open a repo and commit an empty project

npx create-next-app@latest, git init, push to GitHub. Empty project = zero reference point. Every future change is shown as a diff from that empty state.

4. Write SPEC.md before the first prompt

Minimum format: one paragraph – what, for whom, critical screens, data models. Maximum 400 words. Over-specified is also wrong – the agent loses room to suggest things. Write the spec in the expected quality style – that is the style your project will drift towards.

5. Pick the IDE and the model

For beginners: Cursor (easiest UI). Composer in Cursor, Sonnet 4.6 model. If you prefer the terminal, Claude Code. Stick to one tool for the first 30 days, then compare.

6. Hand off tasks “the size of a coffee”

Each prompt should be small enough that the implementation fits in 15-20 minutes and the review in 10. If Cursor types for 40 minutes straight, your task was too big – split.

7. Commit at every step

Ugly commits are fine. After every green change: git add, short conventional commit, keep going. After an hour of work you have a history you can safely roll back to. Without commits you are guaranteed not to know what broke four hours from now.

8. Keep a “later” list separate

The first two days, do not polish styles, do not implement a11y, do not write tests for every component. Keep a TODO.md with the debt list and push the user story toward working. Optimising before working is a recipe for early burnout.

9. Deploy to staging first, prod second

Vercel preview deploy on every PR – open it in the browser, see if it really works. Locally it always works. On staging it sometimes does not. On prod it becomes your user's problem.

10. Pick one success metric

Something you can measure post-launch. “Three of my teammates use the board five times a week” is a good metric. “App looks nice” is not.

11. Open an issue for every idea you will not do now

Issue tracker (GitHub Issues is enough) instead of an inbox in your head. Every idea, bug, “wouldn't it be cool if” lands as a labelled issue. Five minutes of grouping in the evening – you see what tomorrow should really look like.

12. Schedule a retro after seven days

After a week you sit down, read git log, check the success metric, readTODO.md. Three questions: what works? what slows me down? what to drop? Thirty minutes that lift a project from “just a prototype” to “a product”.

Bonus: do not build a Twitter clone

“Twitter clone” as a first project looks easy because Twitter “has simple features”. It does not. It has auth, infinite scroll, realtime, search, ranking. As a first project, build something you will use yourself next week. Habit tracker, tagged notebook, personal finance dashboard. Small, yours, used.

TL;DR

A first vibecoding project succeeds when you start with a spec, one user story and a boring stack. Commit at every step, optimise at the end, measure success in users. Save the Twitter clone for project five.