A cat napping by a computer

Checklist before shipping a small personal site

Small sites are deceptively easy to ship. They are also easy to forget after launch. A short checklist helps avoid obvious problems and keeps maintenance low.

This is the one I use before I push changes to production.

Reliability

  • Build locally from a clean state (npm run check — same as CI: heroes, build, tsc, Wrangler dry-run)
  • Confirm required environment variables exist in production
  • Verify one happy-path request and one failure-path request for key endpoints
  • Keep at least one previous deploy ready to roll back

If the site has a contact form, I always test end to end:

  1. submit from the UI
  2. confirm provider logs show success
  3. confirm message arrives at the real inbox
  4. confirm reply goes to the sender

SEO and discoverability

  • Page titles and descriptions are specific (not reused across unrelated pages)
  • Canonical URLs are correct
  • Open Graph image exists for pages that matter
  • robots.txt and sitemap are reachable
  • RSS feed renders without errors

For blog posts, I check:

  • one clear headline
  • one practical takeaway
  • internal links to related posts
  • visible publish date

Performance basics

I do not over-optimize personal sites, but I do avoid obvious regressions:

  • large images are compressed
  • no accidental megabyte-sized JS dependency
  • no long-running client-side work on page load

If a feature is optional and expensive, I gate it behind conditions or keep it server-side where possible.

Content quality

Before publishing any post, I ask:

  • Is there at least one thing the reader can apply today?
  • Is there one concrete command, snippet, or checklist?
  • Can someone skim this in two minutes and still get value?

Personal sites do better when posts are useful, not just frequent.

Operational hygiene

  • Secrets are never committed
  • Error messages shown to users are safe and non-sensitive
  • Logs include enough context for debugging but no private data

I also keep changes small. If I cannot explain a deploy in a few lines, it is usually too big for one release.

This looks like a lot on paper, but in practice it takes 10–15 minutes and catches most painful mistakes. The goal is not perfection; the goal is shipping confidently and sleeping well after deploy.

For image weight specifically, Build-time WebP heroes with Astro is what this site uses on the blog. For contact reliability, start with Fix Resend 403 and 422 and Fix Astro API route 404.

Hero image: Computer Cat Nap, freely licensed on Wikimedia Commons.

More Posts

If this topic was useful, these posts cover similar hands-on lessons and real-world workflows.