A vibe coding workflow that actually ships

Vibe coding is brilliant at the first 80%. You describe an app, the agent builds it, and by midnight there's something on localhost that mostly works. The last 20% is where projects go to die: the auth edge cases, the email that never gets sent, the deploy, and the moment two weeks later when you open the repo and can't remember what state it's in.

This guide is a workflow for getting from "it runs on my machine" to "it's live and I can come back to it", without giving up what makes vibe coding fun.

Why vibe-coded projects stall

It's rarely the code. It's the shape of the work:

• One endless chat. The plan lives in a conversation that gets compacted, abandoned or lost.
• No definition of done. Every feature is "mostly working". Nothing is ever finished, so nothing is ever shipped.
• Context switching. A new idea arrives, you start a fresh repo, and the first one never gets reopened.
• Invisible leftovers. The API key you meant to add to production, the DNS record, the "TODO: handle errors". Nobody wrote them down.
• Coming back cold. After two weeks away, restarting costs an evening of archaeology, so you don't.

The workflow below fixes the shape and keeps the speed.

Step 1: describe features in one sentence

Start with outcomes, not tasks. One sentence per feature:

• "People can sign up with email and a password, and verify their address."
• "A dashboard shows clicks per day for each short link."
• "Free users can make 3 links; Pro is unlimited."

That's all you write. You're the product owner; the agent is the team.

Step 2: let the agent split it into small stories

Ask the agent to turn each sentence into a few stories, each small enough to finish in one session, each with three to five checkable acceptance criteria. Review the plan before it's saved.

Plan "a dashboard shows clicks per day for each short link" as a feature:
3-5 stories, each finishable in one session, each with 3-5 checkable
acceptance criteria. Show me before saving.

This is the step that makes everything after it work. Small stories mean every session ends with something finished, and criteria mean "finished" isn't a vibe. There's a whole guide on writing acceptance criteria for agents.

With Klio, the agent reads your stack and existing features with brief_feature, proposes the stories, and saves them with create_feature once you say yes. They appear on a board with IDs like SNIP-F3 and SNIP-12.

Step 3: build by ID

Now each session is one line:

Build SNIP-12.

or just:

continue

The agent loads the story, claims it, builds it, ticks each criterion as it passes, and sends it to review with a short summary. You don't paste context, re-explain the app or decide what's next. If it needs something only you can do (an API key, a DNS record), it puts the exact steps in your inbox instead of leaving a TODO.

Step 4: review, then mark done

Each finished story lands in review with its criteria ticked and a two-line summary. Open the app, check the criteria, and move it to done, or back with a comment if something's off. It takes a minute per story because the criteria are a checklist.

Keeping "done" as your call is what stops a vibe-coded project from filling up with half-finished features that everyone (including the agent) believes are complete.

Step 5: ship early, and write down what's left

Deploy as soon as the core loop works, not when everything's perfect. The deploy is where the hidden work shows up: environment variables, a production database, email sending, a domain. Each of those becomes either a story or a hand-off on the board, so none of it is lost.

A few habits help:

• Keep a list of env var names per environment. Never the values. "RESENDAPIKEY: set locally, missing in production" is exactly the kind of thing you'll forget.
• Record each deploy. What went out, where and when. Klio's record_deploy does this and reports env vars that are missing in production.
• Mark the project's stage. Idea, building, shipped. It changes how you prioritise.

Step 6: stop with a note

Before you close the laptop, the project should say where it stands in two or three sentences:

Analytics is half there: clicks are recorded (SNIP-12 shipped).
The chart is next (SNIP-13). Waiting on a Resend key for the weekly
email; it's in the inbox.

You can write it yourself, but it's better when the agent rewrites it every time it finishes a story. Klio keeps one per project and updates it on every complete_issue.

Step 7: come back weeks later

This is the payoff. Open the project, say "continue", and the agent starts from the note, the board and what changed since last time. No archaeology. The side project you'd normally abandon gets a second evening, and a third, and ships.

If you juggle several projects, this is also what makes switching cheap: each project holds its own state, so jumping between them costs a sentence, not a night.

An evening, start to finish

Here's what the workflow looks like in practice for a small link-shortener project, from an idea to something live.

7:00. You write one sentence: "Short links with a click counter per link." The agent proposes four stories: data model and redirect, create-link form, link list with counts, and deploy. You trim one criterion and approve.

7:10. "continue". The agent builds the redirect route and the links table, ticks the criteria ("redirect answers in under 50 ms locally", "unknown codes show a 404 page"), and sends it for review. You click a test link: it works. Done.

7:40. "continue". The create-link form. It flags that it needs a decision: random codes or custom ones? You answer in the inbox, it finishes, you review. Done.

8:30. "continue". The list with click counts. One criterion fails your review: counts don't update until a refresh. You move it back with a comment; the next session fixes it.

9:15. "continue". Deploy. The agent sets up the production database and records the deploy, and flags that you need to add the domain in your host's dashboard. You do. It's live.

9:30. The resume note says: "Live at links.example. Next: per-day chart for clicks (not planned yet)." You close the laptop. In three weeks, "continue" starts right there.

None of those sessions needed you to re-explain the app, and every one ended with something finished.

The whole loop on one page

1. One sentence per feature.
2. The agent proposes small stories with criteria; you approve.
3. "continue" or "build ID" per session.
4. Review against the criteria; you mark done.
5. Ship early; every leftover is a story or a hand-off.
6. A short note on where it stands.
7. Come back any time and say "continue".

Choosing what to build first

Start with the one path a user takes to get value, end to end, even if it's ugly: sign up, do the main thing, see the result. Build that thinly and ship it before adding settings, themes, admin pages or a second way to do the same thing. A thin working path teaches you more about what to build next than any plan written before it existed.

What you need

• A coding agent that speaks MCP: Claude Code, Cursor, Codex, Windsurf, VS Code with Copilot and others. Setup steps are in the docs.
• Somewhere for the plan to live outside the chat: a board your agent reads and updates. Klio is free for one person and three projects.
• A rules file with your commands and conventions, plus a few lines telling the agent to use the board (see CLAUDE.md vs AGENTS.md).

Common traps

• Planning everything up front. Plan the next feature or two. The rest will change once you see the app.
• Skipping review because the agent said it's done. That's how "done" stops meaning anything.
• Starting a new repo for every idea. Add it as a feature to an existing project if it fits, or start a project on the board and come back to it.
• Letting secrets into chats. Agents should know which variables exist, not their values.