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

> How to version and release software you build with AI agents: small versions, a plain changelog, carrying unfinished work forward and honest release notes.

- URL: https://shotmatic.app/blog/ship-small-versions
- Category: Versions & Releases
- Published: 2026-09-27
- Author: Tu Nguyen

## Key takeaways

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

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](https://shotmatic.app/blog/wont-do-list-scope-creep).

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:

```text
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](https://shotmatic.app/blog/indie-marketing-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.

## FAQ

**How often should a solo developer release?**

As often as a version adds one thing a user would notice. For many indie apps that is every one to four weeks. The rhythm matters more than the number.

**Should I use semantic versioning for a small app?**

A simple form works well: bump the minor number for new features, the patch number for fixes, and keep 0.x until the core promise is stable. Consistency matters more than the exact rules.

**What does 'carry forward' mean?**

When you close a version, every unfinished item is copied into the next version's plan with a note of where it came from. Nothing is lost, and nothing blocks the release.