A "cloud ready" web launch is not a certification. It just means I can build, deploy, and verify the basics without guessing. Most launch problems are boring: the build fails in CI, lint was skipped, an env var is missing, a page 404s, a form does nothing, or the deployed site is serving old assets.

This is the checklist I run before I ship.

The three files

I keep this in the repo so it survives beyond my memory:

FilePurpose
docs/prelaunch-checklist.mdCommands and checks I run before every deploy
docs/smoke-check.mdThe few manual clicks I confirm on the deployed URL
package.json scriptsOne consistent way to run build and lint
Cloud architecture checkpoint illustration for this section.

Prelaunch checklist

# Prelaunch checklist
- `npm run build` passes locally
- `npm run lint` passes locally
- Home page loads on the deployed URL
- One primary user flow works end to end
- 404 page loads or falls back cleanly

The list is intentionally boring. Those are the checks that break most often on small web deploys.

Scripts I rely on

npm pkg set scripts.build="gatsby build"
npm pkg set scripts.lint="eslint ."

Pick whatever matches your stack. The point is to have one way to run build and lint every time, not to remember which command worked last month.

Smoke check

# Smoke check
- Home page loads
- Primary CTA works
- One important interaction works once

After deploying, I repeat those same three clicks on the live URL. Local success does not always match production.

Cloud operations checkpoint illustration for this section.

Optional release note

If I want to avoid the "I think this used to work" problem, I write one line per deploy:

# Release 2025-06-05
- Changed: updated hero layout
- Verified: build, lint, smoke check
- Skipped: nothing

Closing

A prelaunch checklist is only useful if it is short enough to actually run. If it lives in a file, uses repeatable commands, and forces one manual pass before deploy, it will catch most of the boring problems that kill launches.