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 ShotMatic Method.

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.

Where ShotMatic fits

ShotMatic keeps the release side of this cheap: a GIT strip on every board shows what is uncommitted, push shows the file list and a prefilled message before it runs, and marking a task done commits exactly one status file — never git add . behind your back. The phase and next step on each line tell you at a glance which version is close to its promise.