Deployment Checklist

Make the Release Boring Before It Begins

A deployment is the moment a private engineering decision meets customer work. For a solo founder, it is also the moment one person becomes release engineer, operator, support desk, and final authority. A checklist cannot remove that concentration of responsibility. It can keep the founder from discovering the plan while production is already changing.

Use this review for one releasable change. Name the exact source revision or immutable artifact, the behavior it changes, and the customers or data it can reach. If the summary says “miscellaneous fixes,” split the release until a failure can be connected to a plausible cause.

Small changes still deserve a recovery path. The path may be simple: redeploy the previous artifact and verify one customer journey. It may instead require disabling a feature, stopping writes, restoring data, or fixing forward. Decide which before running the first production command.

Establish the Known-Good State

Record what healthy production looks like immediately before deployment. Choose a small set of signals that can reveal the change’s likely failures: a synthetic request through the affected journey, error and latency measures, job or queue health, and one product outcome such as completed imports or successful payments. A green home page says little about a broken billing callback.

Build and test the same artifact that will be released. Confirm its identifier, dependencies, configuration keys, secret references, feature-flag defaults, scheduled jobs, and infrastructure changes. Inspect migration commands instead of treating their successful generation as evidence that they are safe.

Stateful changes need special honesty. Reverting application code does not undo deleted rows, transformed values, messages sent, or writes made in a new format. Prefer a sequence in which old and new application versions can coexist: add before removing, tolerate both representations during the rollout, and postpone destructive cleanup until the new behavior has proved stable. Where coexistence is impossible, name the pause, backup, restore, or fix-forward procedure and test it at a scale that makes its duration credible.

Write the Stop Conditions First

Do not wait for a bad graph to decide what “bad” means. For each rollout checkpoint, write the observation window, the signals to compare with the known-good state, and the condition that stops expansion. Include quiet failures: a queue that grows while requests still return 200, a payment flow that completes without granting access, or a privacy job that reports success while leaving a vendor copy behind.

Use staged exposure when the system permits it. The first stage might be a founder-owned workspace, one background worker, one region, a small traffic slice, or an enabled feature flag for a consenting design partner. Each stage must be large and long enough to exercise the changed path. “No alerts after thirty seconds” is not useful evidence for an hourly job.

Keep the previous release available until the observation window ends. If a stop condition fires, halt expansion first. Then follow the written recovery path. Production is a poor place to improvise several unrecorded changes at once.

Copyable Deployment Plan

Use exact commands, dashboards, queries, artifact identifiers, and owners. “Check logs” and “roll back if needed” are prompts to make decisions during an incident, not a plan.

# Deployment: [one releasable change]

Release owner:
Planned time and observation window:
Customer behavior being changed:
Customers, workspaces, traffic, jobs, or data in scope:
Source revision and artifact identifier:

## Known-good state
Current production version:
Affected journey and synthetic check:
Baseline technical signals:
Baseline product or customer signal:
Known unrelated warnings:

## Preconditions
Build and test command, with result location:
Configuration and secret references verified:
Migration or data-change command reviewed and tested:
Old/new version compatibility:
Backup or recovery prerequisite, when needed:
Feature flag or other containment control:
Customer or support communication needed:

## Rollout
Exact deployment command or workflow:
Stage 1 scope:
Stage 1 observation window and checks:
Condition to expand:
Next stages and checks:
Final version or configuration check:

## Stop and recover
Stop conditions:
Command or control that halts expansion:
Recovery choice: rollback | disable | stop writes | restore | fix forward
Exact recovery steps:
Data written or transformed during the rollout:
How that data remains compatible or is reconciled:
Recovery verification:
Customer message and channel if impact occurred:

## Close
Post-deployment check after normal usage:
Release record, artifact, and evidence links:
Temporary flags, compatibility paths, or resources to remove later:
Owner and trigger for that cleanup:
Outcome: completed | recovered | held for investigation

The plan is ready when another careful operator could tell what is changing, execute the release, judge each checkpoint, and recover without guessing. For a solo founder, that future operator is often the same person under worse conditions.

Worked Release: The Agency Import

The reporting product from the Privacy Checklist now rejects unused contact fields and deletes uploaded source files after a short recovery window. The change includes application code, an additive expiry field, a deletion job, and object-storage configuration. A single “deploy succeeded” result cannot show that imports still complete or that files disappear when promised.

The founder releases an identified artifact with the new path disabled by default. A synthetic agency workspace supplies a file containing permitted metrics plus forbidden email and free-text columns. The first checkpoint proves that the report is correct, the forbidden fields never reach analytics or error tracking, the expiry record exists, and the deletion job removes the source object. The next stage enables the path for one design partner and watches import completion, job lag, storage deletion, and support messages for a full cycle before wider exposure.

The recovery plan distinguishes reversible code from irreversible effects. The founder can disable new imports and restore the previous application artifact. That does not recreate a file already deleted, so the release retains the old and new metadata representations until the observation period is complete and does not promise data resurrection. If expiry metadata is wrong, rollout stops before the deletion job is enabled; if the job has already acted correctly, recovery preserves the deletion rather than treating it as damage.

Close the Release, Not Just the Terminal

A deployment ends after the changed customer journey has survived ordinary use, not when the command exits. Record the running version, the evidence observed, any customer impact, and the temporary compatibility work left behind. Give every flag, duplicate path, elevated permission, or old schema element an owner and a removal trigger. Otherwise the safety mechanism becomes permanent operating burden.

If recovery depends on a backup that has never been restored, it is still a hope rather than a recovery path. Test that dependency with the Backup and Recovery Checklist before release.

If the release was recovered, keep the record. It should say which stop condition fired and what the system did, without turning the event into a story of heroics. The useful outcome is a smaller next release and a deployment path that has become easier to trust.