Cloud Ready Web Checks: A Small, Honest Prelaunch Checklist

A “cloud ready” web launch is not a special certification. It just means you can build the site, deploy it, and verify the basics without guessing. Most problems at launch are boring problems: the build fails in CI, lint was never run, environment variables are missing, a page 404s, a form does nothing, or the deployed site is serving old assets.

This post is a small prelaunch checklist you can add to any web repo. The goal is not perfection. The goal is repeatability. You should be able to run the same commands before every deploy and know what “good” looks like.

This is still a guide. It is start to finish. But first, here is what you are actually building.

What this checklist is

You are adding two docs files and a few scripts so your repo has one place that says what you check before deploying. The checklist is not a blog post idea or a concept. It is a file in your repo that you can open and follow.

This setup gives you three outcomes.

First, you have a written checklist that stays with the project.

Second, you have consistent commands to run for build and lint.

Third, you have a tiny manual “smoke check” list that forces you to click the most important user flow once before you publish.

I cannot verify these steps from this blog repo. Treat this as a lab guide you can run locally in your own project.

What you need before you start

You need a web repo that uses Node tooling and has a package.json. You also need a build command that works locally, or at least a way to create one. If you are using Gatsby, Next.js, Vite, or plain React, you already have the pieces.

If you do not know your build command yet, that is fine. You will identify it in Step 2.

The final structure you will end up with

Before we do steps, this is the target. It is small on purpose.

Once these exist, you can run the checks in a couple minutes and keep shipping without guessing.

Start to finish

Step 1: Add a real checklist file

Create a file at docs/prelaunch-checklist.md. This is your single source of truth. Keep it short enough that you will actually run it.

Create the folder and file:

mkdir -p docs
cat > docs/prelaunch-checklist.md <<'EOF'
Prelaunch checklist
- Build passes locally
- Lint passes locally
- Home page loads on the deployed URL
- One primary user flow works end to end
- 404 page loads (or at least a non-broken fallback)
EOF

This list is intentionally boring. It covers the checks that break most often on small web deploys.

Verify the file exists and is readable:

cat docs/prelaunch-checklist.md

If this fails with “file not found,” you either did not create the folder, or you created the file somewhere else. Fix that before moving on.

Step 2: Make build and lint repeatable through scripts

The checklist is only useful if the checks are easy to run. That is why scripts matter. Scripts also prevent the “I ran a different command last time” problem.

Open package.json and make sure you have build and lint scripts.

Here are examples for common stacks. Use the one that matches your project.

Instead of typing JSON by hand, set scripts with npm pkg set so the command is repeatable. Pick the block that matches your stack and copy/paste it.

For Next.js:

npm pkg set scripts.build="next build"
npm pkg set scripts.lint="next lint"

For Gatsby:

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

For Vite:

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

For Create React App:

npm pkg set scripts.build="react-scripts build"
npm pkg set scripts.lint="eslint ."

If npm run lint fails because ESLint isn’t installed yet, set up a minimal lint config first. If your repo already has ESLint, skip this section.

npm i -D eslint
npx eslint --init

If you don’t want the interactive init, this is a minimal config that works for plain JavaScript projects. Create it and run lint again.

cat > .eslintrc.cjs <<'EOF'
module.exports = {
  env: { browser: true, node: true, es2021: true },
  extends: ["eslint:recommended"],
  parserOptions: { ecmaVersion: "latest", sourceType: "module" },
  rules: {}
};
EOF

Once scripts are set, run them.

npm run build
npm run lint

Both commands should exit successfully. If one fails, do not ignore it. Fix it until it passes, or update the checklist to match reality. The point is to stop lying to yourself about what you checked.

Step 3: Write a small smoke check you can actually perform

Automation will not catch everything. You still need one quick manual pass. Keep this list short. Three items is enough.

Create docs/smoke-check.md:

cat > docs/smoke-check.md <<'EOF'
Smoke check
- Home page loads
- Primary CTA works (button or link)
- One form or important interaction works once
EOF

Now actually run the app locally and do those three things once. If your app has no form, replace it with something real, like “one login works,” or “one project card opens,” or “search returns results.”

After you deploy, repeat the same three clicks on the deployed URL. Local success does not always match production.

Step 4: Add a quick deploy note when you ship

This step is optional, but it stops the “I think this used to work” problem. Write one small release note per deploy.

DATE="2025-06-05"
mkdir -p docs/releases
cat > "docs/releases/${DATE}.md" <<'EOF'
Release 2025-06-05
- Changed: updated hero layout and image sizing
- Verified: build, lint, smoke check
- Skipped: nothing
EOF

Change the DATE value and the bullet lines to match what you actually shipped.

How you know the setup is done

At this point, you should be able to answer three questions with files and commands, not memory.

If those are true, you now have a prelaunch checklist that is real.

Common problems and what to check first

When something goes wrong, it usually points back to one of these.

This table is not exhaustive. It is just the common boring stuff that breaks launches.

Closing

This checklist is not about being perfect. It is about being able to deploy without guessing. Keep the list short enough that you run it every time, and keep the scripts consistent so checks are repeatable.

If you want to expand later, add one accessibility scan and one simple end to end test. But do not add more checks until you are running the basic ones every deploy.