Most studios go quiet after launch. The site goes live, the studio sends the final invoice, the team posts a LinkedIn announcement. Three months later something breaks and nobody quite knows who's responsible.
We do this differently. The first 90 days after launch are where the real work happens. The site is live but it isn't yet proven. The metrics that mattered in development (Lighthouse scores, accessibility audits) are now joined by metrics you couldn't measure before (real users, real traffic, real conversion).
This is what we watch during those 90 days, what we act on, and what we leave alone.
Hour zero: launch readiness
Before launch, a checklist:
- 301 redirects in place for any URLs that changed.
- DNS TTL lowered to 5 minutes the day before, raised back to 24 hours a week after.
- Backups confirmed working and restorable.
- Monitoring (Sentry, uptime, analytics) confirmed firing on staging.
- Smoke-test script ready to run against production immediately post-cutover.
- A rollback plan documented and tested.
We don't launch on Fridays. We don't launch the day before someone goes on vacation. We don't launch when half the team can't be online for the next four hours.
Hour 1-24: surface checks
The first 24 hours are mostly about catching the things that only show up in production.
What we watch:
Error rate. Sentry's error volume should spike briefly at launch (traffic increase reveals errors), then drop within 4-6 hours. If it doesn't, something specific is broken. Common culprits: a missing environment variable, a CORS issue with a new third-party, a route handler returning 500s.
Uptime monitoring. External pings should be returning 200s. If any region shows downtime, we check the CDN and DNS.
Conversion paths. Manually walk the contact form, the signup flow, any payment paths. Things that worked in staging sometimes don't work in production because of subtle environment differences (different API keys, different feature flags, different domain CORS rules).
Indexing. Submit the new sitemap to Google Search Console. Confirm the homepage gets indexed within a few hours. The first crawl is a useful signal that the technical SEO is correct.
Email deliverability. If the site sends transactional email, send a test to a Gmail address and a Yahoo address. Confirm it lands in the inbox, not spam. SPF/DKIM/DMARC misconfigurations show up here, fast.
If everything looks normal after 4 hours, the immediate launch crisis is over. The next phase is observation.
Day 1-7: trends, not point-in-time
The first week is about establishing the new baseline.
What we look at, daily:
Real-user Web Vitals. Lighthouse synthetic scores are one number. Real-user CrUX data is the truth. The first 7 days of real traffic tells you whether Performance is actually 100 for real users on real devices, or whether the lab score was misleading.
We watch for: LCP percentiles by device class, INP outliers, CLS issues that didn't show up in the lab.
Search Console impressions. A new or rebuilt site takes days to reaccumulate ranking. Don't panic if impressions drop on day 1. Watch the trend over the week.
Bounce rate and time on page. The first week shows how the new site performs against the old baseline (if you had analytics on the old site). Significant bounce-rate increase on key landing pages is a sign something's worse.
Conversion funnels. Did the contact form's submission rate hold? Did the demo signup rate hold? If conversion dropped after launch, the new design might be performing worse on the metrics that matter, regardless of how it looks.
We don't act on day 1 numbers. We act on day 4-5 numbers, where you have enough data to know whether something is a trend or noise.
Day 7-30: optimisation opportunities
The first month is when the targeted optimisations start.
What we work on:
Pages that don't perform. If a service page is converting at half the rate of the others, we A/B test. If the blog index has high traffic but low click-through to articles, we redesign the cards. The data tells us what to prioritise.
Search Console issues. "Crawled - currently not indexed" pages. "Soft 404" warnings. Pages that are getting impressions but no clicks (suggesting the title or description isn't doing its job). Each one is a 30-minute fix.
Real-user performance. If CrUX shows INP issues on mobile that the lab missed, we hunt them down. Usually a JavaScript interaction blocking the main thread, often in a third-party widget.
Content gaps. If users are searching for terms the site doesn't cover (visible in Search Console), we either add a page or rework an existing one. The site's content map should adapt to what visitors are actually looking for.
This is where the maintenance plan structure pays off — we have hours allocated to do this work without it being a separate project every time.
Day 30-90: stabilisation and learnings
By month two and three, the site has settled into a new baseline. The work shifts from optimisation to insight.
What we look at:
Three-month conversion deltas. Compare conversion rates to the pre-launch baseline. Is the new site genuinely better? On which pages? By how much? Some pages improve dramatically; others stay flat; rarely, some get worse. Honest measurement.
Top-traffic pages. Which pages are getting the most traffic, and is that the traffic mix you wanted? Sometimes a blog post you didn't expect to rank becomes the top entry point. That's a signal to invest more in that topic.
SEO ranking position. Where are you ranking for the keywords that matter? Has the rebuild moved them up, down, or sideways? Use ranking tracking (Ahrefs, SEMrush, or Search Console for position averages).
The "first 90 days report." At the end of the period, we write a short report: what changed, what improved, what didn't, what we'd do differently. The client reads it. We discuss it together. It informs the next phase.
This is the report most studios don't write. It's the most useful single document of the whole project.
What we do, week by week
The cadence we hold for the first 90 days:
Daily (week 1): check error rate, uptime, smoke-test the key flows.
Weekly (weeks 2-12): review Search Console, CrUX, conversion metrics, error logs. 30-60 minutes. Document anything that needs follow-up.
Bi-weekly (weeks 2-12): a 30-minute sync with the client. What we noticed, what we acted on, what we want to know from them.
Monthly: a written report. Lighthouse scores (current vs. launch baseline), Search Console (impressions, clicks, top pages), conversion metrics, what we worked on, what's planned.
Day 90: the "first 90 days report." Comprehensive look back, recommendations forward.
That's the rhythm. It's not heavy; it's about 4-6 hours per week of total time. It catches issues early and produces a document trail of what's been done and what's worked.
Why this matters
The honest reasons we do this:
It catches problems before they compound. A bug at launch that's not caught for 30 days is a bug that's been affecting users for 30 days. The cost of slow detection is real, even if the bug looks small.
It generates the learnings that inform the next project. The "first 90 days report" tells us, for the next project, what to prioritise in design and engineering. The studio that doesn't review launches doesn't learn from them.
It earns the next phase of work. Clients who see attentive post-launch monitoring stay clients. The maintenance contract, the next feature, the referral to their network — these come from a relationship that didn't end at launch.
It's the honest version of "we care about the work." Most studios say this. Few of them are still answering DMs about the site in month four. The ones that are are usually the ones the client recommends.
A short summary of the framework
- Hour 1: surface checks (error rate, uptime, smoke tests).
- Day 1-7: establish the real-user baseline (Web Vitals, conversion, search).
- Day 7-30: targeted optimisation based on what the data shows.
- Day 30-90: stabilisation, deeper insight, retrospective.
If you're launching something or you've launched recently and want a structured post-launch period, start a conversation. We bake this into every project we ship, but we also do it as a standalone for sites we didn't build.