Getting a prototype into production is hard work. By launch day, many founders are more relieved than excited. The tests pass, the security review is done, someone signed off, and it is live.

It is tempting to treat that as the end. It is closer to the start. Everything before launch was a careful guess about how people would use the product. After launch, you get to see.

In my process, the last step, Ship, loops straight back to Test. What real users do after launch plans the next round. Here is how I set that up, starting before the release goes out.

Agree on one metric before launch

Your requirements brief named one metric that matters. Before launch, turn it into something you can measure.

Pick a number that moves when users get what they came for, not one that moves just because people showed up. Sign-ups and page views tell you about your marketing. Completed tasks, submitted applications or the time from request to approval tell you whether the product works. Selling my startup, Stacks, to EBSCO taught me that vanity numbers do not survive a serious conversation.

Write down three things:

  • The metric, defined so two people would count it the same way.
  • Today's number, from before the product existed.
  • What would count as working, and how long you will wait before judging.

Add two or three guardrails alongside it, such as errors, support requests and drop-off in the core flow. They are not the goal. They tell you when something is wrong.

One metric keeps the team honest. With ten, someone can always find a number that went up.

Instrument it before you ship

If the metric is not tracked on launch day, you lose the first weeks of data, and those weeks are often the most revealing.

  • Name the events that make up the metric, usually the start and the finish of the core flow, in plain words.
  • Track them where they happen. An event that matters, like a completed sign-up, is usually better recorded on the server when the record is saved than in the browser when a button is clicked. Vercel's custom events docs, for example, say it is more useful to track sign-ups and purchases on the server.
  • Test the tracking on a preview. Do the events fire once, with the right data? A number that counts twice is worse than no number, because people believe it.
  • Keep personal data out of events. Track that something happened, not who it happened to. Rules on analytics and consent vary by place, so check your local rules.
  • Send errors to a named person. Alerts nobody owns get ignored.

Have the rollback path ready before you need it, too. I cover that in previews, environments and rollback, and the wider pre-launch list is in what still needs to happen before launch.

Watch real use in the first days and weeks

The first days are about breakage. Watch errors, failed sign-ins and the step where people stop. Real devices, real data and real networks find things previews don't. Check every day.

The first weeks are about behavior. Which features get used, which get ignored, where people drop off in the core flow and what they do that nobody predicted. Check every week, and be careful with early numbers. With only a few users, one busy customer can move the metric on their own.

Production shows things no test session can. That is a reason to watch closely, not a reason to panic when it surprises you.

Talk to the first users

Numbers tell you where something is happening. People tell you why.

Get in touch with your first users in those first weeks. Ask to watch them do a real task, the same way you ran test sessions before launch. A few questions I keep coming back to:

  • "What did you come here to do?"
  • "Did it work?"
  • "What did you do instead when it didn't?"

Treat support requests the same way. Each one is a finding, and it goes on the same ranked list as your test findings, worst problems first. I wrote about building that list in fix the worst problems first.

Keep the release notes plain

After launch you will ship often. Every release should still go through tests, a security review and a named person's sign-off. Humans keep launch authority after launch as much as before it.

Each release gets a short note for users: what changed, what got fixed and anything they need to do. Plain words, no internal names.

Generated notes are a starting point, not the finished thing. GitHub's automatically generated release notes, for example, list the merged pull requests and the contributors. That is useful to your team. Your users need it rewritten as what changed for them.

Plain notes also show your first users that you listened. When the thing someone reported is fixed, tell them.

Plan the next round from real use

Your backlog was written before anyone used the product. Much of it is still guesses.

So don't pick up the old backlog where you left off. Start a new ranked list from what real use showed: test findings, support requests, the drop-off points and the metric. Then go through the old backlog and keep only what real use supports. The rest waits.

Then the loop starts again. New previews, real users trying them, the worst problems fixed first and another release.

Launch is the start of the loop, not the end of the project.

A checklist for the first month

  1. Before launch: one metric, clearly defined, with today's number and what would count as working.
  2. Before launch: events named, tracked and tested on a preview.
  3. Before launch: error alerts going to a named person, and a rollback path ready.
  4. First days: watch errors, sign-ins and where people stop.
  5. First weeks: watch the metric and drop-off, and talk to your first users.
  6. Every release: tests, a security review, sign-off and a plain release note.
  7. Next round: planned from real use, not the old backlog.

If you have launched and aren't sure what to watch, email me and I'll point you in the right direction.