A launch-day checklist a coding agent can run

Launches fail on things that were fine yesterday: an environment variable that exists locally and not in production, a form that works on localhost and is refused from the real domain, a Slack hook that was switched off after a bad deploy three weeks ago. The list below is what to check. The second half is how to have an agent check most of it.

The list

Money

1. The payment provider is in live mode, the webhook endpoint is the production URL, and a test purchase with a real card has been refunded.
2. Prices on the pricing page match the catalogue. Yearly is a real discount, stated as a number.

Signup path

3. The signup form on the landing page works from the production origin. If a browser key is restricted by origin, the production origin is registered, not just localhost.
4. The secret key is used only in server code, and the file holding it is in .gitignore. Grep for the prefix in the client bundle.
5. The form records where the signup came from: referrer and UTM values, passed as a source. Without this, tomorrow’s “which post worked” has no answer.
6. Confirmation and invite emails render on a phone, and the link in each lands where a new user can act.

Announcement

7. A changelog entry for the launch is written and scheduled for launch time, so the changelog is not empty on the day people look.
8. The people on the waitlist will be told: an announcement email drafted and previewed, or invites planned in batches (fifty, then five hundred).

Watching it happen

9. Something tells you when a signup arrives: a Slack or Discord webhook that is enabled and whose last delivery succeeded.
10. Feedback has a place to land, and someone will read it that day.
11. You know which three numbers you will look at tomorrow morning, and where.

Outside any tool

12. DNS TTLs are short, the status page exists, error tracking is on, and the person on call is not also the person posting on Hacker News.

Having an agent run it

Items 3 to 11 are readable from a repository and a launch tool’s API. If the Nordva Launch MCP server is connected in Claude Code, Cursor or Claude Desktop, the launch_day_checklist prompt does exactly this. It:

• calls setup_check for the plan, what is locked, and whether the project still has the default name (the slug is in every public link);
• reads waitlist stats and settings: how many are waiting, whether the list is paused, whether a welcome URL is set, how many an invite batch would reach;
• lists the latest changelog entries and offers to draft a launch entry if there is none;
• reads the codebase for the form, the source passing, the secret key’s location, the ignored env file and the registered origin;
• lists webhooks and their last delivery;
• checks the Stripe connection status, and says in one line what connecting it would let you see;

then reports Ready, Fix before launch (at most five items, most important first, each with the exact next step) and After launch (the numbers worth checking tomorrow and the tool that shows each). It changes nothing without asking.

Type /launch_day_checklist in a client that lists prompts, or ask: am I ready to launch? Setup is one command, npx nordva@latest init, described on the MCP page.

What it cannot check

Items 1, 2, 6 and 12. The agent cannot see your payment dashboard, click a link in an email on a phone, or read your DNS. Do those by hand, the day before, and write down what you saw.

The morning after

Three numbers, not thirty: signups by source (get_attribution_report or the dashboard’s Growth page), how many confirmed, and feedback with an email address on it, because those are people you can write to. Everything else can wait until the week’s end.