How Should You Manage a Feature Backlog in Vibe Coding?
A useful feature backlog can be much smaller than a traditional planning board. Choose a place for ideas based on how you build and how easily work gets lost.
Your AI coding session just produced three feature ideas while you were fixing one bug. Do you leave them in the chat, put them on a board, or stop to plan the whole product? How to manage a feature backlog in vibe coding depends on where ideas get lost and how much coordination your build needs. For a solo project, a smaller backlog may help you ship more than a fully populated board.
A feature backlog is simply a place for possible product work that you have not committed to doing yet. Its job is to help you choose the next useful slice without confusing an idea with an active task. Answer the questions below based on what is happening in your project, rather than how an established team might plan its work.
Are feature ideas getting buried in your coding chats?
ChatGPT and AI coding tools such as Cursor are useful places to explore an idea while you work. Chat history is a poor place to see all the ideas competing for your attention. A suggestion made during debugging can be hard to find when you sit down to choose the next feature, and copying an entire conversation into a new session brings along plenty of irrelevant context.
If you are losing ideas this way, give each promising feature its own short entry outside the chat. Write the user-facing outcome and, if helpful, the source of the idea. Leave implementation details for the build session. When a suggestion appears in chat, capture it before changing topics, then return to the bug you were solving.
Do you need to choose between ideas or coordinate active work?
A short document or spreadsheet can work well when you build alone and only need to compare a handful of possibilities. Give each item a name, a reason it matters, and a rough state such as possible, next, or in progress. Keep the list selective. If every passing thought becomes a feature, you have made the next choice harder.
An issue tracker becomes more useful when work needs owners, review, or dependencies across people. It asks for more upkeep, which can be worthwhile when another person must understand what is blocked. For a solo build, use the smallest list that lets you choose your next slice. For shared implementation work, choose a tracker your collaborators can reliably keep up to date.
Is a quick fix turning into a product feature?
During a build session, you may notice that users need to edit a saved draft, not merely create one. First note the observation where you are working. Then decide whether it changes the current slice or deserves its own feature entry. A bug in the promised draft-saving flow belongs with the work in progress; a new editing capability can wait in the backlog.
That distinction protects momentum. You can finish and verify the current flow without pretending the new idea never happened. Promote the idea when you can state its outcome clearly enough to choose it later. If you cannot yet explain who it helps or what would count as done, keep it as a note rather than an active feature.
For a concrete example of sorting build-session notes into repairs and feature candidates, see this worked example of turning coding notes into a feature pipeline.
Can you tell what to build when you return?
Open your project after a few days away and look only at your backlog and latest work note. Can you identify the current feature, the next candidate, and the reason the current work stopped? If not, update those entries before generating more code. An elaborate ranking system will not repair an unclear feature state.
VibeCrumbs keeps feature candidates alongside your daily build notes, so a todo discovered during a session can be promoted into its feature pipeline when it is ready. If that fits the way you work, keep your feature backlog in VibeCrumbs. Your next session should begin with a choice you can act on, not a search through old chats.