Three days from launch, the boss drops a message: "We're live tomorrow, right?" That's when you discover the payment test was never run, the mobile form won't submit, and Google still indexes the old site. We've seen too many projects where the problem isn't development — it's the lack of a pre-launch acceptance checklist. One missed 301 redirect can cut traffic 30%; one untested payment webhook can mean orders that never collect money. Here is a 15-point checklist you can follow directly.
When it fits vs when it doesn't
This checklist fits:
- Owners outsourcing for the first time who want to know "what acceptance even covers."
- Redesigns that most fear losing SEO rankings.
- Sites with payments, memberships, or forms — features where errors are expensive.
It doesn't fit:
- Pure static one-page brochure sites with no interaction (checklist can shrink).
- Early MVPs deliberately shown to a few testers.
- Engineering teams with mature DevOps and automated CI/CD gates.
Alternatives matrix
| Approach | Pros | Cons | Cost tier |
|---|---|---|---|
| Professional acceptance (vendor-delivered checklist) | Clear ownership and accountability | Needs acceptance criteria in the contract | Included in project fee |
| Self-check against a list | Zero cost, you know the business best | Easy to miss technical items (perf, SEO) | Low (labor hours) |
| Just trust the dev's "it's fine" | Fast | Highest risk, blame games when it breaks | Looks low, actually costliest |
Full process (5 days before launch)
- T-5 feature freeze (deliverable: feature reconciliation sheet): stop adding features, fix bugs only. Tools: Notion/Trello.
- T-4 cross-device testing (deliverable: compatibility report): walk every page on iPhone/Android/desktop. Tools: BrowserStack or real devices.
- T-3 payment and form testing (deliverable: transaction screenshots): run full payment and callback via ECPay test env or Stripe test cards.
- T-2 performance and SEO (deliverable: Lighthouse report): confirm LCP under 2.5s, set 301 redirects and sitemap.
- T-1 backup and monitoring (deliverable: rollback plan): confirm DB backup, SSL cert, error monitoring (Sentry) are ready.
Real cost breakdown
- SSL: basic certs are usually free via host (Let's Encrypt); EV certs from ~NT$3,000/yr.
- Payment fees: credit cards ~2.0%–2.8%, eat into margin — price them in.
- Third-party services: SMS OTP (~NT$1–2 each), maps API, email (SendGrid/Resend) — free tiers exist but overage bills.
- Post-launch maintenance: security updates, backups, monitoring — budget 15%–20% of dev cost per year.
- Hidden hours: cross-device testing and webhook debugging are routinely underestimated — reserve 2–3 working days.
Reality vs what clients imagine
- Clients think "launch = done"; the first 30 days of monitoring and tuning are the real quality line.
- Clients think "looks good on desktop is enough"; over half of traffic is mobile — that's the main stage.
- Clients think "payment connected means money arrives"; without testing the webhook, "customer paid, system didn't record" is common.
Common traps and how to avoid them
- Forgetting to remove noindex: the dev-stage block on search engines left on → check indexability in Search Console before launch.
- Old links 404: paths changed after redesign without redirects → export old URLs and set 301s one by one.
- Only testing payment success, not failure: refunds, timeouts, lost callbacks untested → run failure scenarios too.
- Form emails never arrive: mail lands in spam or SPF/DKIM unset → configure domain auth and send a real test.
- No rollback plan: can't restore fast when launch breaks → back up first and prepare one-click rollback.
Success metrics and a 90-day roadmap
- 30 days: watch error rate, load time, form/checkout completion; fix the top three drop-off points.
- 60 days: watch Search Console index coverage and organic recovery; add content and internal links.
- 90 days: watch conversion and order value; decide the next optimization round by data (A/B test key pages).
Decision checklist (pre-launch self-check)
- ☐ Tested every page on all three device types?
- ☐ Tested both payment success and failure paths?
- ☐ Set 301 redirects for all old URLs?
- ☐ Removed noindex/robots search blocks?
- ☐ LCP under 2.5s?
- ☐ Form emails actually arrive (not spam)?
- ☐ DB backup and rollback plan ready?
- ☐ SSL cert and auto-renew set?
- ☐ Error monitoring (Sentry, etc.) installed?
- ☐ Launch owner and emergency contact confirmed?
FAQ
Should the acceptance checklist be in the contract?
Strongly recommended. Putting acceptance criteria in writing (three device types, payment webhook, LCP threshold) avoids "is it done?" disputes after launch and protects both sides.
I'm not technical — how do I accept performance and SEO?
Free tools do it: Google Lighthouse for performance, Search Console for index status. Ask the vendor to deliver screenshots of both; you only need to confirm the numbers pass.
Whose fault is a post-launch bug?
Depends on the warranty period. Most projects include 1–3 months; in-period non-new-feature bugs should be fixed by the developer. Define warranty scope and response time in the contract.
Traffic dropped after the redesign — now what?
Check 301 redirects and noindex first — the two most common causes. Then review index coverage in Search Console; usually it's a missed technical setting that recovers in 2–4 weeks once fixed.
Call to action
Need a launch-acceptance checklist tailored to your site, or someone to guard the launch day? Free consultation:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p