Ship notes: what to write down when the work was not a commit

Try this: write down everything you shipped last week without looking at anything.

Most people manage three items and know they are missing several. The work is not memorable in the way it deserves - it is memorable for about forty hours and then it is gone, replaced by this week's version of the same thing.

Now look at your commit log. It fills in the code. It also proves the point, because the moment you read it you will remember two or three things you shipped that produced no commits at all.

The gap the commit log leaves

A commit log is an excellent record of one thing: changes to a codebase, by whoever made them, when.

Here is a partial list of things that ship without producing one.

You changed your pricing page. You rewrote the onboarding email that everyone was ignoring. You answered a support question so well that you turned the reply into documentation. You migrated a database with no application change. You cut a plan nobody bought. You configured something in a dashboard that fixed a class of bug. You made a decision about scope and told the two people it affected.

Every one of those changed something for someone using your product. Not one of them appears in git log.

For a solo founder this gap is not a rounding error. Depending on the week, the majority of what you shipped may be outside the repository - and if the only record you keep is the commit history, that work is simply not written down anywhere.

The note

A ship note is one line, written when it happens, saying what changed for the person using your product.

That is the entire specification. Deliberately smaller than a changelog entry: no version, no category, no bullet hierarchy, no release cadence, no publishing step. It has to cost about eight seconds, because anything more expensive stops getting written in exactly the weeks worth recording.

Four rules make them useful later:

Past tense. "Rewrote the trial email" is a ship note. "Working on the trial email" is a status update, and a status update ages into a lie.

Name the user-visible change, not the task. "Split the settings page into three tabs" beats "settings refactor". Later you will want to know what a user would notice, and the task name will not tell you.

One specific noun. Which email, which page, which plan. Ship notes with no nouns are indistinguishable from each other three weeks on.

No adjectives. Not "significantly improved onboarding". Improved how? Cut two steps? Removed a required field? Say that instead; it is shorter anyway.

Bad and good

Improved the onboarding experience.

Unusable. In a month you will not know what changed or whether it worked.

Cut onboarding from five steps to three by dropping the company-size and role questions.

That is a record, a post, a changelog entry, and the beginning of an argument about what else can go.

Fixed some bugs.

Which? Whose?

Fixed the logout button not ending the session on Safari.

Someone who hit that bug will be relieved to read it, which is the test.

When to write it

At the moment it ships, not on Friday.

Friday reconstruction fails in a specific way: you remember the big thing and lose the four small ones, and the four small ones are often the ones users actually noticed. It also turns a seconds-long habit into a scheduled task, and scheduled tasks compete with everything else on a Friday afternoon.

Where to keep them matters much less than people think. A text file at the root of the repository. A pinned note. An issue you keep appending to. The only requirement is that the friction of adding a line is close to zero, and that you can find them later.

What they are worth later

Once you have a few weeks of these, they turn out to be worth more than the eight seconds each:

• They are a changelog when you need one, without the ceremony of maintaining one continuously.
• They are what you post. A specific past-tense line about a user-visible change is already 80% of a good build-in-public post, which is the point of what to post on the weeks you shipped nothing.
• They answer "what have I been doing?" honestly - a question that hits hardest in exactly the weeks when the honest answer is a lot, and it does not feel like it.
• They make quiet weeks legible. A week with no ship notes was genuinely a week with no shipped changes. That is information, not a gap in your records.

Why this matters for a marketing tool

Full disclosure about why we care, because this word is ours and we use it in the product.

PeerPost writes posts grounded in what you shipped, and it reads two kinds of evidence: commits from the repositories you connect, and ship notes you write yourself. Once they arrive, the pipeline does not distinguish between them - a ship note grounds a post exactly as a commit does.

That has one consequence worth stating plainly: you do not need a repository to use PeerPost. A founder whose product is not a codebase, or whose most important work this month happened in a dashboard and a pricing page, connects nothing and writes ship notes instead. The posts are just as specific, because specificity came from the note, not from the source it arrived through.

Start writing them either way. The habit is worth more than any tool that reads them.

If you want the notes turned into posts that market what you shipped, request an invite.