The MVP launch checklist we run before every site goes live

Launching too early is a myth clients hear too often. Launching without a real MVP launch checklist is where projects actually go sideways, because the things that break in the first 48 hours are almost never surprises to anyone who was looking.

We’ve shipped enough sites and custom web apps to know that a disciplined pre-launch pass isn’t bureaucracy. It’s the difference between a clean handoff and a panicked Slack message at 11 PM on a Friday. Here’s the list we actually run.

Start with what the user will actually touch

Before anything else, we load the site on a real phone. Not browser DevTools mobile simulation. A real phone on a cellular connection. If a button is too small to tap, if a form field kicks the viewport sideways, or if the hero image takes four seconds to settle, we know before the client does. These aren’t edge cases. They’re the first things real visitors encounter.

Every form gets a live submission test. Contact forms, quote requests, checkout flows, newsletter signups. We check that the confirmation email arrives, that the data lands in the right place (CRM, spreadsheet, inbox), and that the thank-you redirect works. Broken forms are the single most common way a site silently loses leads in week one.

The technical layer most people skip over

SSL should be active and forcing HTTPS across every URL, including subdomains. Canonical tags need to be set so the site doesn’t index both www and non-www versions. The robots.txt should not be blocking search engines (we’ve seen staging-era settings survive into production more times than we’d like to admit). And the sitemap should be submitted to Google Search Console on launch day, not a week later.

We also confirm that 301 redirects are in place for any URLs that changed from the previous site. Losing existing link equity because someone forgot to map the old blog structure is an avoidable own goal. If the project included SEO and technical audit work, the redirect map is already documented. If not, we build one before touching the DNS.

Performance before the public sees it

A Lighthouse score below 70 on mobile performance is a launch blocker for us, not a post-launch to-do. Images should be in WebP format, properly sized for their display dimensions, and lazy-loaded below the fold. JavaScript should be deferred where it’s safe to defer. Render-blocking resources in the head get audited.

For WordPress builds specifically, we make sure caching is configured (LiteSpeed Cache, WP Rocket, or the host’s native layer), and that query strings aren’t defeating the CDN. A slow launch is harder to recover from than a delayed launch, because first impressions travel fast and Google’s Core Web Vitals data starts accumulating from day one. Our WordPress speed optimization process addresses all of this before the go-live call.

The pre-launch checklist in short

When we’re doing the final pass, these are the items that earn a checkbox before we point DNS:

• All forms tested end-to-end with real submissions and confirmed delivery
• SSL active, HTTPS forced, no mixed-content warnings in the browser console
• 301 redirects mapped and verified for any changed URLs
• Mobile Lighthouse performance score above 70, images in WebP, caching on
• Google Search Console connected, sitemap submitted, robots.txt confirmed open to crawlers

What happens after the MVP goes live

An MVP launch is not a finished product. It’s a testable version of something real. The discipline shifts from building to observing. We set up Google Analytics 4 with basic conversion events (form completions, button clicks, checkout steps) so the first month of traffic is actually readable data, not just pageview noise.

We also document the WordPress environment clearly: PHP version, active plugins with versions, theme, and hosting specs. Not because we expect disaster, but because the next person to touch this site (including future us) will need that information. A good handoff document takes 30 minutes and saves hours later.

For clients who want the site actively maintained after launch, our care and maintenance plans cover ongoing updates, uptime monitoring, and security patches so the MVP doesn’t quietly degrade over the following months.

If you’re approaching a launch and want a second set of eyes on the build before you flip the switch, book a free 30-minute call and we’ll tell you exactly what we’d check first.