Product

Pre-Launch Technical Checklist for a Website or MVP

Run a practical pre-launch checklist for security, backups, monitoring, performance, SEO, analytics and handover of website or MVP accounts and source code.

Apex Labs / / 5 min read

Before you launch, confirm that the site is served over HTTPS with sensible security settings, that secrets are out of the code, that a backup has been restored at least once, that errors and downtime will reach a human, and that the client owns every account. The list below is ordered by what hurts most when missed.

Tick items off in a ticket or a shared doc. Some items need judgment, so each has a short explanation.

Security

  • HTTPS everywhere. Redirect HTTP to HTTPS and enable HSTS once HTTPS and renewal are reliable; add includeSubDomains only after checking every affected subdomain. See MDN on Strict-Transport-Security.
  • Security headers. At minimum a Content-Security-Policy (start in report-only mode), X-Content-Type-Options, a Referrer-Policy, and frame protection. In Next.js you set these in next.config (headers docs). Background on CSP: MDN CSP guide.
  • Secrets out of git. Search history for API keys and database URLs. If any was ever committed, rotate it. Use environment variables in the host, not files in the repo.
  • Separate environments. Production uses its own database, keys, and webhooks. No shared credentials with staging.
  • Dependency audit. Run npm audit and turn on automated updates (npm audit, Dependabot). Fix high-severity issues that affect code you actually ship.
  • Authentication basics. Hashed passwords or a hosted provider, session expiry, and a tested password reset. Details in the authentication guide.
  • Authorization checks on the server. Hiding a button is not access control. Test that user A cannot read user B's data by changing an ID.
  • Rate limits. Login, signup, password reset, OTP, and any endpoint that sends email or SMS. See rate limiting patterns.
  • Input validation and file uploads. Validate on the server. Restrict upload type and size.
  • Review against the OWASP Top 10. A pass through the list catches common mistakes.
  • Admin areas. Require strong authentication and server-side authorisation. Keep them out of search, while remembering that an obscure URL or noindex is not access control.

Backups and restore

  • Automated database backups. Confirm the schedule and retention in your host or database provider.
  • A restore test. Restore a backup into a fresh database and check the app runs against it. A backup you have never restored is a hope. Postgres background: continuous archiving.
  • File uploads protected. Confirm backup or versioning coverage, retention and restore. Durable object storage alone does not protect against accidental deletion.
  • Know your recovery targets. How much data loss and downtime can the business accept? Write it down.

Observability

  • Error tracking. Frontend and backend errors go to a tool such as Sentry (docs), with alerts routed to a real person.
  • Uptime monitoring. An external check on the home page and one key authenticated or API route, with email or phone alerts.
  • Logs you can search. Structured logs with request IDs, retained long enough to debug a week-old issue. Do not log passwords, tokens, or full card or ID numbers.
  • Health endpoint. A cheap route that checks the database connection.
  • Alert ownership. Name who gets the 2 am alert. If nobody, say so explicitly.

Performance

  • Core Web Vitals on real pages. Test the key pages on a mid-range phone and a throttled connection. Targets and definitions are on web.dev. More in Core Web Vitals for Next.js.
  • Images. Correct sizes, modern formats, explicit dimensions, lazy loading below the fold.
  • Caching and CDN. Static assets cached with long lifetimes. Public pages cached where safe.
  • Database indexes chosen from measured query plans and realistic data; indexing every column adds write and storage costs. Check the slowest queries with realistic data.
  • A basic load check. Not a benchmark, just enough to know one signup spike will not take the site down.

SEO basics

  • Indexable. No leftover noindex from staging, and robots.txt allows crawling.
  • Titles, descriptions, canonicals, sitemap, and structured data are in place. Use the full Next.js SEO checklist.
  • Redirects from old URLs if this replaces an existing site (migration guide).
  • Search Console verified and sitemap submitted.
  • 404 page that helps people get back.

This is a practical list, not legal advice. Have a qualified professional review these for your business.

  • Privacy policy describing what you collect, why, who processes it, and how users can contact you. Check applicable privacy requirements with a qualified adviser for each jurisdiction and data category.
  • Terms of use or terms of service.
  • Cookie or consent notice if you use non-essential cookies or tracking and regulation applies to your audience.
  • Refund, cancellation, and shipping policies if you take payments. Payment providers commonly ask for these.
  • Business details such as company name and contact address in the footer.
  • Forms that collect data link to the privacy policy.

Analytics

  • Core events tracked (signup, activation, purchase, key form submits). See what to track in an MVP.
  • Internal traffic and test data excluded.
  • Consent respected where required.
  • Conversion goals tested end to end in production.

Access and handover

  • Domain registered in the client's name, with the client as owner and billing contact.
  • DNS hosted in an account the client owns. Document every record and why it exists.
  • Cloud, hosting, and database accounts owned by the client, with the agency or developers added as members, not the reverse.
  • Third-party services (email, payments, analytics, error tracking) under client accounts.
  • Credentials in a password manager with shared vaults. Not in chat, email, or a spreadsheet.
  • Two-factor authentication on registrar, DNS, hosting, email, and source control.
  • Source repository owned by the client's organisation.
  • A short runbook: how to deploy, roll back, rotate a secret, restore a backup, and who to call.
  • Renewal dates for domain, SSL (if not automatic), and paid services in a shared calendar.

Final pass

  1. Test the main user journey on a phone, in production, with a real account.
  2. Send a test email, SMS, or WhatsApp message and check where it lands.
  3. Do a dry-run rollback.
  4. Freeze changes for a short window around launch and watch error tracking.

Apex's product development work includes a month of post-launch tuning, with scope described on the service page; agree who owns incidents and fixes before launch.

References

  • launch checklist
  • security
  • backups
  • monitoring
  • handover
  • mvp