Shipping Solo: The Friday Checklist

When you work alone, every mistake is a surprise to exactly one person, and it's the person who's also on call. Tallowbrook has no QA team, no reviewer and no release manager. What it has is a Friday ritual and a very short script that says no.

I've shipped on Fridays for a year. People tell me that's reckless, and they have a point if the process is judgement. Mine is a checklist, and a checklist doesn't have bad days.

The script

It does three things. It refuses to continue if git status shows anything at all: edits, staged changes, or a new file that was never added. It runs the tests. It tags the commit with a date-based version. Nothing in it is clever:

#!/bin/bash
set -euo pipefail
test -z "$(git status --porcelain)" || { echo "dirty tree, commit first"; exit 1; }
node --test >/dev/null
tag="v$(date +%Y.%m.%d.%H%M)"
git tag "$tag"
echo "tagged $tag"

set -euo pipefail is the line doing the most work: any failing command stops the script, so a red test can't be followed by a tag.

I ran it in a scratch repository. The first run printed tagged followed by a version made of the date and the minute, such as v2026.09.12.0820. Then I appended a line to a tracked file and ran it again, and it printed dirty tree, commit first and exited with status 1. A stray untracked file gets the same refusal, and a failing test stops it before the tag. That refusal is why it exists. The worst releases I've done were ones where the code I shipped wasn't the code I'd tested, because something uncommitted was sitting on my machine.

The rules around it

The script covers the mechanical part. These cover me:

1. Nothing new after Thursday noon. Friday is for finishing, not starting. If a change isn't ready by Thursday it waits for next week.

2. Every release has an undo. Before I tag, I write down how to roll back, in one line. If I can't write it, I don't ship.

3. Migrations ship alone. A database change goes out a day before the code that uses it, never in the same release.

4. I read the diff. Not the code, the diff since the last tag. Ten minutes, out loud, as if explaining it to a colleague I don't have.

What I got wrong first

My first version of the script also deployed. That felt efficient and it was a mistake: a script that tags and deploys can't be run safely to see what it would do. Now it only tags. Deploying is a separate command that takes the tag as an argument, so I can always answer "what exactly is live?" with one word.

I also tried a longer checklist, twenty-odd items in a note. I stopped reading it after a month. The five things above survive because each one was bought with an outage.

The honest limit

None of this replaces a second pair of eyes. It replaces the version of me who's tired at 5 p.m. with a version who was careful at 9 a.m. and wrote it down. If you work alone, that's worth more than it sounds.