Ship Small Versions: A Release Rhythm for AI-Built Apps

AI agents make it very easy to never ship. There is always one more feature the agent can add in ten minutes, one more refactor, one more screen. A week later the "small update" has twenty changes, none tested together, and you are afraid to release it.

The fix is a rhythm: small versions, released on purpose, with the rest carried forward. This is part 5 of The Solo AI Builder Method.

The short answer#

• Release as soon as a version does one useful thing; agents make it tempting to keep adding, so the release date has to be a decision.
• Every version has a short plan, a won't-do list and a changelog written for users, not for git.
• Unfinished work is carried forward into the next version's plan, never silently dropped or used to block the release.
• Release notes must be honest about what is untested or unsigned.

A version is a promise, not a pile of commits#

Before starting a version, write three short things:

1. The one-line promise — what a user can do after this version that they couldn't before.
2. The scope — the phases or tasks that deliver that promise, and nothing else.
3. Won't do (this version) — tempting things you are explicitly postponing. See the won't-do list.

When the promise is delivered and checked, the version is done — even if the backlog is long.

Folder per version, not a forever to-do#

A simple structure that works well with agents:

plan/
  v0.3/
    plan.md        # promise, scope, won't-do
    state.md       # current phase and next step
    CHANGES.md     # draft release notes as you go
  v0.4/
    plan.md        # starts with items carried forward from v0.3

The agent always works inside the current version's folder. Old folders become a readable history of what you planned versus what shipped.

Carry forward, don't drop, don't block#

When you close a version, three things can be true of each unfinished item:

• It is still wanted → copy it into the next version's plan with (from v0.3).
• It is no longer wanted → move it to the won't-do list with a one-line reason.
• It is blocking the promise → then the version isn't done; finish it first.

What you never do is leave unfinished items floating in an old plan where nobody will look again, or hold a working release hostage to a nice-to-have.

Changelogs for humans#

Git history is for you. The changelog is for users. Write it as you go, not at release time:

• Lead with what the user can do, in bold: "Quick Chat — open a new session in any project in one click."
• Mention renames and anything that moves user data.
• Group by version, newest first, with an Unreleased section at the top.

An agent can draft the changelog from the version's plan and diff; you edit it. That keeps it accurate without costing an evening.

Be honest in release notes#

Say what is not done. "Windows build: code written, not yet tested." "The macOS installer isn't signed yet." Users forgive missing things; they don't forgive discovering them. It is also better marketing than it sounds — see indie marketing for many small products.

The release checklist#

Keep it short enough to actually run every time:

1. Every task in scope passes its exit check.
2. Changelog updated, version number bumped in one place.
3. All repos involved are committed and pushed.
4. Tag the release.
5. Close the version folder and carry forward what is left.

Keep reading#

• Phases, Not To-Do Lists: Project Management for Solo Devs
• The Won't-Do List: How to Stop AI Agents From Scope Creep
• Indie Marketing When You Build Many Small Products