Pick the go-live date, then count back a week. A go live checklist for a web app is the short list of switches that must be set before that date, each checked by a named person: production configuration, live payment keys, DNS and TLS on the real domain, the email sending domain, search indexing, and a rollback already rehearsed.
The go live checklist: what has to be true, by area
A go-live checklist for a web app is a list of switches, not tasks: production configuration, live payment keys, DNS, TLS, the email sending domain, backups, monitoring, search indexing, a recent security test and a support owner. Each one is done when someone can show the evidence that it is set.
Going live is the launch milestone of production hardening, the point where everything done to the app meets its first real customer. Whether the software itself holds up for people who are not you is a separate verdict, with seven evidence gates, in whether your AI-built app is ready to launch, and the full engineering list is the production readiness checklist. This page does not re-run either one.
The software can pass every test on staging and still fail this go-live checklist, because a switch lives in configuration and accounts, not in the code. That is the whole importance of a go-live checklist: a switch left unset stays invisible until the first real customer hits it (my reading). Every row below is a property of the running application, which is why this go-live checklist has no rows like “write tests” or “finish onboarding”.
The table is one go-live checklist example, filled in for a typical web app. The switches and the evidence are my list; the last column names the page that owns the detail, so this one stays short.
| Area | The switch | The evidence it is set | Who owns the detail |
|---|---|---|---|
| 1. Production configuration | Every environment variable and key set for production; the auth provider on its production instance | The production config read back, key by key, not a working login | release readiness checklist |
| 2. Payments | Live mode on, with no test keys left in production | The evidence the payment page asks for | payment go-live checklist; for Stripe, Stripe test mode to live mode |
| 3. Domain and DNS | Every record written down; the TTL lowered ahead of the switch where the host allows it (my working rule) | The record list matches what the DNS host shows. On Cloudflare a proxied record’s TTL is Auto (300 seconds) and cannot be edited; a DNS-only record’s TTL can be set from 60 seconds to 1 day outside Enterprise | The plan and the undo table below |
| 4. TLS on the live domain | A certificate issued and valid for the real domain | The certificate’s issuer and expiry, read in the browser; Let’s Encrypt’s default certificates are valid for 90 days | add HTTPS to your website |
| 5. Email | The sending domain authenticated | A received message’s authentication results | SPF, DKIM and DMARC setup |
| 6. Backups | A restore that worked, from the live database’s backups | The restored copy and the date it was made. Where the host’s plan keeps no backup, this row is a no-go until one exists (my reading) | database backup checklist for startups |
| 7. Monitoring | An error reaches a named person | A test error that reached that person | logging and monitoring |
| 8. Search indexing | noindex removed from production, robots.txt no longer blocking the site, the sitemap submitted | The live page’s headers and HTML show no noindex; the sitemap is in Search Console (owner permissions needed) or listed in robots.txt | The cutover, step 5 |
| 9. Security test | A test of the live app within about the last month (my working rule) | The report and its date | web application security testing services; the budget version, affordable penetration testing |
| 10. Support | An inbox someone answers, and a named owner for the first week | A test message that got a reply | The first-week section below |
Row 8 clears two settings that interact. Google says a noindex rule only works when the page is not blocked by robots.txt, so a staging setup that used both needs both removed. It also calls submitting a sitemap “merely a hint”: the evidence is the live page as Google can fetch it, not the submission.
The configuration row is the one a working app hides best. One app I audited in June and July 2026, a fitness-plan app, had its backend wired in committed code to its auth provider’s development instance while the app was live, with no way to switch it per environment. Moving to a production instance would log out every user until that line changed. The lesson I take from it: a working login proves nothing about which instance it logs into, so the configuration row is checked by reading the production configuration, never by signing in.
A go-live readiness checklist asks whether each of these rows is true today, which is why every row names its evidence rather than a task. Before launching the app, check every row against its evidence yourself, even the ones someone else set up; this checklist before go live is short enough to read in one sitting.
For a SaaS product with its marketing site on the same domain, the website go-live checklist shares three rows with the app’s: DNS, TLS and search indexing. A website release checklist for every later deploy repeats rows 1 and 8, because any release can bring back a development key or a stray noindex tag. Nothing here needs a project office: the whole system is one web app, so each row of its go-live checklist has one owner page and one person who checks it.
What is go-live?
Go-live is the moment an app starts serving real customers with real data and real money. From then on every change is a change to production, so the switches that make it safe are set before that moment.
That is my definition for a web app. In project-management language, go-live is the move from a project to an operation: the team hands a finished system to the people who will run it. For one web app it comes down to one cutover and one decision. The announcement is a separate event and can come later; go-live is the first real sign-up, the first real payment, the first record that somebody would miss.
The new product launch checklist and the go-live one
A new product launch checklist is a different list with a different owner. It holds the announcement, the launch posts, the pricing page, the onboarding emails and the store listings, and the steps in order, with the whole-launch calendar counted back from the date, are in how to launch an app.
A website pre-launch checklist is the content half of the same split: the copy, the forms, the redirects from old URLs and the analytics tag. A Webflow launch checklist, or one for any other site builder, is that content half for a site the builder hosts, and it runs next to this list rather than in place of it. A simple product website launch checklist is the same content half at its smallest, for a site of a few pages.
Business readiness and change management go-live checklists are the enterprise names for training people and telling them what changes; a web app with its first customers has little of either, and this page leaves both out. The two lists share one date and one go/no-go call.
Before the go/no-go call: the go-live plan
A go-live plan is the go-live checklist with an owner, a date, an evidence link and a lead time on every row. The lead times set the order: the DNS TTL change and the email records go in days ahead, and the rollback is rehearsed before the call.
The pre go-live checklist is this plan, and the pre go-live activities are its rows worked back from the date by lead time. My working rule is to start it about a week before the date, earlier when the DNS or email lead times need more. Go-live planning and preparation both start from the longest lead time, so work this checklist by that column, longest first, not by area.
| Switch | Owner | Date checked | Evidence link | Lead time |
|---|---|---|---|---|
| 1. Production configuration | Set on the build you will promote; read back before the call | |||
| 2. Payments | As the payment go-live page says | |||
| 3. Domain and DNS | TTL lowered at least one old-TTL period before the switch (my working rule) | |||
| 4. TLS on the live domain | At the cutover with HTTP-01 on a host that issues the certificate for you; can be done ahead with DNS-01 | |||
| 5. Email | Records published a few days before the first real email (my working rule) | |||
| 6. Backups | A restore finished before the call | |||
| 7. Monitoring | A test error delivered before the call | |||
| 8. Search indexing | At the cutover, step 5 | |||
| 9. Security test | Booked so the report is no more than about a month old at the call (my working rule) | |||
| 10. Support | Inbox tested and first-week owner named before the call |
The DNS lead time is my working rule: lower the TTL at least one old-TTL period before the switch, so the old value has had time to expire in caches by the time you point the record at the live host. The reason is in Cloudflare’s TTL reference: TTL controls how long each record is cached, and so how long a record update takes to reach users.
The certificate’s lead time depends on how it is issued. Let’s Encrypt’s HTTP-01 challenge, “the most common challenge type today”, puts a file on your web server at http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>, so the domain has to reach the server first. On a host that issues the certificate for you, that puts issuance in the cutover, step 3, not days ahead; the DNS-01 challenge proves control with a TXT record instead, which is why it can run before the switch (my reading of Let’s Encrypt’s docs).
The sending domain’s records go in a few days before the first real email, which is my working rule for the timing. The requirement itself is Google’s: every sender to Gmail accounts must “Set up SPF or DKIM email authentication for your sending domains”, and senders of more than 5,000 messages a day to Gmail accounts need SPF, DKIM and DMARC.
Two items have no row of their own. The rollback is rehearsed once on staging before the call, and the release readiness page owns how. A load check against the expected first-week peak belongs to the scaling readiness checklist for startups. The technical checks run on the readiness article’s calendar, and the store and announcement dates on the launch article’s calendar; neither is restated here.
A go-live plan template is this table with the dates blank; a go-live plan example is the same table filled in. The table also works as a pre go-live checklist template, and for a website go-live checklist template you keep the same columns and drop the payment row.
A software or project go-live checklist template, in Excel or any other tool, is these columns copied across; there is nothing to download, because the table is the template. A go-live readiness checklist template in Excel, or a readiness assessment template, adds a pass or fail column, and a project go-live readiness checklist adds a sign-off column too. An IT or project management go-live checklist is the enterprise version, with training and data migration rows added, and a move to production checklist template is the same list under another name.
The go/no-go call
The go/no-go call is a written decision, not a meeting that runs out of time: who decided, the evidence read, go, no-go or go with dated conditions, and the rollback trigger agreed before the cutover starts. Any switch without evidence is a no-go for that switch.
This is the record I’d keep, in my own format: six lines, written before anyone touches production.
- 01 Who decided, by name, and who else was in the room
- 02 The plan, read row by row with each row's evidence open, not summarized
- 03 The outcome: go, no-go, or go with conditions, each condition with an owner and a date
- 04 The rollback trigger, agreed before the cutover starts: the symptom or number that means undo, not debate
- 05 The freeze: nothing merges after the call except the rollback
- 06 The time the decision was written down
The go/no-go live checklist is the plan’s ten rows read as criteria, and the decision is taken on the evidence column, whatever the calendar says. The conditions that stop a launch outright for the software are the readiness article’s, and they are not restated here. A go/no-go checklist for IT projects adds training, data migration and formal sign-offs, the enterprise version, which a single web app mostly skips. The meeting itself, with a reviewer who did not build the app, is the production readiness review, which this page does not cover.
The cutover, in order
A web app’s cutover runs from the most reversible switch to the least: promote the tested build, switch payments to live, point DNS and confirm TLS, check one real email, open search indexing, run one real journey, and announce last.
The steps involved in the go-live procedure for one web app are these seven, each with the evidence to keep:
- 01 Promote the tested build through the release gate the release readiness page describes. Evidence: the deployed commit id.
- 02 Switch payments to live as the payment go-live page says. Evidence: whatever that page asks you to keep.
- 03 Point DNS at the live host and confirm TLS on the real domain. Evidence: the certificate's issuer and expiry date.
- 04 Send one real transactional email and read its authentication results. Evidence: the full header, which Gmail shows under Show original.
- 05 Remove noindex from production and submit the sitemap in Search Console. Evidence: the URL Inspection result for the live home page.
- 06 Run one real journey end to end on the live domain, from sign-up through the core action. Evidence: the record in the database.
- 07 Announce only after the watch window agreed in the call has passed clean. Evidence: the time the window closed.
The order is my working rule: reversible switches first, the announcement last. What to watch in the step 7 window is the readiness article’s launch-day pass.
Step 3 is where the certificate lead time from the plan lands. Let’s Encrypt’s challenge types add one more condition: the HTTP-01 challenge “can only be done on port 80”, so a new host that keeps port 80 closed cannot get its certificate that way.
Step 5 needs a Search Console property you own for the domain. The Sitemaps report needs owner permissions, and URL Inspection only reads a URL that is “in the current property”. Without a property, the evidence is a Sitemap: line in robots.txt, which Google accepts in place of the report, plus a fetch of the live page’s headers and HTML showing no noindex (the fetch is my method). If a staging robots.txt that blocks everything is still in place, Google’s noindex documentation explains the row 8 trap in full.
After go-live: support in the first week
The first week after go-live is an operations week: a known-issues log with owners, support answered on time, a status page ready, the DNS TTL raised back, the first live backup confirmed, and a review that closes every condition.
The post go-live checklist is short, and every item on it has a person attached. Start a known-issues log on day one, with an owner per issue. Answer the support inbox within the time your terms promise, and keep a status page for a small SaaS ready for the first interruption.
Two infrastructure items close the switch work. Raise the DNS TTL back once the switch is stable (my working rule), and confirm the first backup of the live database, not only the staging one.
Then hold a go-live review about a week in, and close or re-date every condition from the call. Hypercare is the enterprise word for this week. The post go-live support checklist in full is the post-launch support checklist, and the account-lifecycle checks (password reset, refund, deletion) belong to the readiness article’s first-week pass.
What to do if something fails
A switch that fails at cutover is undone first and diagnosed second: roll back the build, point DNS back, or turn one feature off. Write down the time, the symptom, the action and the result before trying again.
The table has one row per switch that can fail at cutover; it is my list. How to roll back on Vercel or Netlify, and when to fix forward instead, is in how to roll back a deployment.
| Switch | The undo | The evidence the undo worked |
|---|---|---|
| The build | Roll back to the previous deployment | The previous commit id is serving again |
| DNS | Point the records back at the old host; a short TTL means the change reaches users sooner | The old host answers on the domain |
| Payments | The undo the payment go-live page gives | What that page asks you to check |
| A single risky feature | Switch that feature off, where a flag exists, instead of rolling back everything | The product works with the feature hidden |
Keep that record as the undo happens, one line per attempt, so the retry starts from what happened rather than from memory.
A quiet go-live day is harder to read than a loud one. Of the 21 third-party apps I audited, 17 had no error tracking or alerting: when a user hits an error, nothing records it. Those 21 come from my June and July 2026 audits, 11 public apps audited across all 12 pillars and a held-out set of 10, and they are a selected set, not a random sample or a rate for AI-built apps in general. My reading: in an app like that, “nothing looks wrong” on go-live day is not evidence.
In the Production Hardening Sprint, two deliverables cover this section’s undo. Deliverable 7.6 documents and rehearses release rollback, including how database changes are handled safely, and is verified this way: roll back a test release and verify application behavior and retained data. Deliverable 7.12 adds a flag mechanism for risky features and third-party dependencies so any one of them can be turned off without a deployment, and is verified by disabling a flagged feature in production and confirming the product stays usable with the feature hidden.
Where the sprint fits
In the sprint, days 8 to 10 verify and hand over. Deliverable 13.1, the production readiness report, delivers the result for every scope item, the work completed and its verification evidence, and it is verified this way: “Account for all 123 IDs; keep failures visible until resolved and explain genuine non-applicable items.” Deliverable 7.13 enforces HTTPS everywhere with HSTS and a CAA record, locks the registrar, documents the DNS records and confirms renewal ownership, and is verified by passing an external TLS scan at the top grade and filing a DNS record export in the runbooks. Deliverable 11.1 verifies and configures SPF, DKIM and DMARC for the transactional sending domain, and is verified by inspecting DNS and received message headers for the configured authentication results. Building new product features or modules sits outside the sprint, as does completing unfinished core features or business workflows. Each deliverable, with its verification line, is in the published scope.
Common questions about going live
What is a go live checklist?
A go live checklist is the list of switches that must be set, and shown to be set, before an app serves real customers. For one web app my list runs to about ten rows, from the production configuration to a named support owner, and each row carries the evidence that proves it.
What is included in a go no go checklist for go live?
A go/no-go checklist for go live includes every switch’s evidence, the verdict on whether the software holds up, the rollback trigger, the owner on call during the cutover, and the written decision with its time. That is my list for one web app rather than an enterprise rollout.
What is a go live readiness assessment?
A go live readiness assessment is the go-live checklist with a pass or fail column and a date, read by someone who did not build the app. The format of that review is its own subject, the production readiness review.
What are go-live plans?
Go-live plans are the checklist with an owner, a date, an evidence link and a lead time on every row, sorted so the longest lead time starts first. That is my wording; enterprise plans add training and data migration on top.
If this checklist left you with more open items than you expected, the sprint below works through all of them in ten working days.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase