After You Ship

The worst way to learn about an outage is a message from someone who hit it an hour ago. Two things fix most of that, and both are free at small scale.

1. 1

   Error tracking

   Sentry or your host's built-in equivalent. It reports what broke, on what page, with the stack trace and browser.

   This is the single highest-value thing to add after launch.

2. 2

   Uptime checks

   A service that loads your site every few minutes and emails you when it stops responding.

You are not building an observability practice. You are answering two questions: is it up, and is it throwing errors.

Real reports are vague. “It doesn’t work” is the median. Your job is to convert that into something reproducible before you prompt anything.

The fourth catches a surprising share of issues outright — a layout that only breaks on Safari, or a feature that assumed a mouse.

Once you can reproduce it, the loop is the one you already know — with one addition that stops the same bug returning:

Users on Safari cannot submit the contact form. I reproduced it:the date field stays empty and the submit button does nothing.Works in Chrome. Relevant file: src/components/ContactForm.tsx First write a test that reproduces this, then explain the cause,then fix it.

Test first, cause second, fix third. The test is what makes this a permanent fix rather than a temporary one.

Analytics answer questions your intuition cannot. Which pages do people land on? Where do they leave? Which feature you spent a weekend on has never been used?

A privacy-respecting analytics tool — Plausible, Fathom, or your host’s built-in option — is a few lines to add and does not require a cookie banner. Start with page views. Do not build a dashboard nobody reads.

A shipped project needs maintenance that is easy to skip because nothing is visibly broken:

1. 1
   Update dependencies monthly

   npm outdated shows what has moved; run your check command after updating.

2. 2
   Act on security advisories

   npm audit, and GitHub will open PRs for you if you enable Dependabot.

3. 3
   Keep your rules file current

   It rots, and a stale one confidently misleads the AI.

4. 4
   Delete what is unused

   Every feature nobody uses is still code you have to keep working.

Most projects get few users, and that is a normal outcome rather than a failure. The value of shipping is not traffic — it is that reality gives you feedback that imagination cannot.

One real user hitting one real bug teaches you more about building software than another week of adding features in private. Ship the small thing, watch what happens, and let that decide what you build next.