The Pre-Deployment Checklist for Your Web App: What to Verify Before You Ship

Every team ships a broken deploy at least once. The difference between a minor hiccup and a full-blown incident is whether you caught the obvious stuff before it reached production. This checklist is not theoretical. It is the exact list we run through at ADBEAM before every release for clients across Europe.

Whether you are launching a SaaS product, an internal tool, or an e-commerce platform serving customers in the EU, these checks cover the areas that cause 90 % of post-launch fires: authentication holes, missing input validation, performance regressions, legal compliance gaps, and the classic "we have no way to roll this back."

1. Authentication & Authorization

Auth is the front door to your application. Get it wrong and everything behind it is exposed: user data, admin panels, billing. Before you deploy, verify that users only access what they are supposed to.

• All auth flows tested end-to-end: signup, login, logout, password reset, OAuth/SSO
• Role-based access control verified so every role can only reach its own resources
• Password reset links expire after a single use and after a time limit (e.g. 30 minutes) so old emails cannot become account takeovers
• Session tokens rotate on login and are invalidated on logout
• MFA enabled for admin accounts and sensitive operations
• API endpoints require authentication with no accidental public routes

Audit my web app for authentication and authorization issues before deployment. Check: Are all auth flows (signup, login, logout, password reset, OAuth) tested end-to-end? Is role-based access control enforced so users can only access their own resources? Do password reset links expire after one use and after a time limit? Do session tokens rotate on login and get invalidated on logout? Is MFA enabled for admin accounts? Are there any API endpoints that are accidentally public? List every issue you find with severity and a fix.

2. Input Validation & Sanitization

Bad data and attacks like XSS, SQL injection, and command injection slip through unvalidated inputs. The rule is simple: never trust the client. Validate and sanitize everything on the server.

• Server-side validation on every endpoint (client-side validation is UX, not security)
• All user input sanitized before rendering or storing, especially HTML and rich text
• Parameterized queries or ORM used everywhere with zero raw SQL concatenation
• File uploads validated for type, size, and content (not just the extension)
• Unexpected fields rejected using an allowlist approach, not a blocklist

Review my codebase for input validation and sanitization gaps. Check: Is there server-side validation on every API endpoint? Is user input sanitized before rendering or storing (especially HTML/rich text)? Are all database queries parameterized with zero raw SQL concatenation? Are file uploads validated for type, size, and actual content? Are unexpected fields rejected using an allowlist approach? Show me every endpoint or form that is missing validation.

3. CORS & Rate Limiting

An open API is an invitation. CORS and rate limiting are your bouncers. They decide who gets in and how often.

• CORS configured so only approved origins can talk to your API with no wildcard "*" in production
• Rate limiting active so spam and brute-force attacks do not crush your backend
• Sensitive endpoints (login, password reset, payment) throttled more aggressively
• Proper 429 responses returned with Retry-After headers
• Rate limit state persisted across instances (Redis or equivalent) if you run multiple servers

Audit my API configuration for CORS and rate limiting. Check: Is CORS restricted to specific approved origins (no wildcard "*" in production)? Is rate limiting active on all public endpoints? Are sensitive endpoints (login, password reset, payment) throttled more aggressively? Do rate-limited responses return 429 with a Retry-After header? If I run multiple server instances, is rate limit state shared (e.g. via Redis)? List any misconfigurations.

4. Security Headers & Data Protection (GDPR)

If you serve users in the EU, and especially in Germany, Austria, or Switzerland, data protection compliance is not optional. It is law. But even beyond legal requirements, proper security headers prevent entire classes of attacks.

1. 1HTTPS enforced everywhere with no mixed content and HSTS header set
2. 2Security headers configured: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
3. 3Cookie consent implemented and compliant with ePrivacy / GDPR requirements
4. 4Privacy policy published and linked from every page
5. 5Data processing agreements (DPA) in place with all third-party processors
6. 6Legal notice / Impressum page live (mandatory for EU-facing businesses)

Check my web app for security headers and GDPR/data protection compliance before launch. Verify: Is HTTPS enforced everywhere with HSTS? Are security headers set (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)? Is cookie consent implemented and compliant with ePrivacy/GDPR? Is there a published privacy policy linked from every page? Are data processing agreements in place with all third-party services? Is a legal notice (Impressum) page live with full company details? List every gap.

5. Frontend Error Handling

Your users should see clean fallback states instead of crashes. A white screen or a raw stack trace destroys trust faster than any bug.

• Global error boundary catches unhandled exceptions and shows a friendly fallback
• API error states display meaningful messages, not technical details or stack traces
• Loading and skeleton states present for all async data
• Custom 404 and 500 error pages designed, branded, and tested
• Offline and network-failure states handled gracefully

Audit my frontend for error handling completeness. Check: Is there a global error boundary that catches unhandled exceptions and shows a user-friendly fallback? Do API error states show meaningful messages instead of stack traces? Are loading/skeleton states present for all async data? Are custom 404 and 500 error pages designed and tested? Is there an offline or network-failure fallback? Show me every component or route that could crash without a clean fallback.

6. Performance, Core Web Vitals & Database

Google uses Core Web Vitals as a ranking signal, and your EU users on mobile connections will not wait around. Performance is not a nice-to-have. It directly affects conversions and SEO.

1. 1Core Web Vitals targets met: LCP < 2.5 s, CLS < 0.1, INP < 200 ms
2. 2Images optimized (WebP or AVIF), lazy-loaded below the fold
3. 3CDN configured with edge nodes in Europe for low latency in DACH markets
4. 4JavaScript bundle size audited with no unused dependencies shipped
5. 5Database indexes added on all key queries so they stay fast under production load
6. 6N+1 query patterns eliminated by checking your ORM logs
7. 7Connection pooling configured and tested under concurrent load

Analyze my web app for performance and database readiness before production deployment. Check: Do Core Web Vitals meet targets (LCP < 2.5s, CLS < 0.1, INP < 200ms)? Are images optimized and lazy-loaded? Is a CDN configured with EU edge nodes? Is the JS bundle size reasonable with no unused dependencies? Are database indexes set on all frequently queried columns? Are there any N+1 query patterns? Is connection pooling configured? List every performance risk with estimated impact.

7. SEO & Meta Tags

• Canonical URLs set on every page to avoid duplicate content issues
• hreflang tags configured for multi-language sites (especially EN/DE)
• Open Graph and Twitter Card meta tags present with correct images
• Structured data (JSON-LD) added: Organization, BreadcrumbList, FAQ where relevant
• XML sitemap generated and submitted to Google Search Console
• robots.txt reviewed so nothing important is accidentally blocked
• Page titles and meta descriptions unique per page, under character limits

Audit my web app for SEO and meta tag completeness before launch. Check: Does every page have a canonical URL? Are hreflang tags set for multi-language pages (especially EN/DE)? Are Open Graph and Twitter Card meta tags present with correct images? Is structured data (JSON-LD) added for Organization, BreadcrumbList, and FAQ schemas? Is an XML sitemap generated and submitted? Is robots.txt reviewed so nothing important is blocked? Are page titles and meta descriptions unique and within character limits? List every missing or broken element.

8. Accessibility (WCAG 2.2)

Accessibility is not just ethics. It is increasingly law. The European Accessibility Act requires digital products to meet WCAG standards, and individual countries are enforcing it.

• Full keyboard navigation works so every interactive element is reachable without a mouse
• Color contrast meets 4.5:1 ratio for normal text
• All images have descriptive alt text
• ARIA labels on interactive elements that lack visible text
• Focus indicators visible and styled
• Screen reader tested (VoiceOver, NVDA, or equivalent)

Check my web app for WCAG 2.2 accessibility compliance. Verify: Can every interactive element be reached and operated via keyboard alone? Does color contrast meet the 4.5:1 ratio for normal text? Do all images have descriptive alt text? Are ARIA labels present on interactive elements without visible text? Are focus indicators visible and properly styled? Test the main user flows as a screen reader user would experience them. List every accessibility violation with WCAG criterion and fix.

9. Environment & Configuration

1. 1Environment variables separated with no secrets in source code or Git history
2. 2Production env vars set and verified (API keys, database URLs, third-party tokens)
3. 3Custom error pages (404, 500) deployed and rendering correctly
4. 4URL redirects configured for any changed routes or legacy paths
5. 5DNS records verified and propagated with SSL certificate active and auto-renewing
6. 6Hosting region confirmed as EU (important for GDPR data residency)

Review my deployment environment and configuration for production readiness. Check: Are all secrets stored in environment variables and not in source code or Git history? Are production env vars set and verified (API keys, DB URLs, third-party tokens)? Are custom 404 and 500 error pages deployed and rendering? Are URL redirects configured for changed routes or legacy paths? Are DNS records verified and propagated with an active auto-renewing SSL certificate? Is the hosting region confirmed as EU for GDPR data residency? Flag anything that looks wrong.

10. Logging & Alerts

Logging so you can see what broke in production. Alerts so you hear about issues before your users do. Without both, you are flying blind.

• Structured logging (JSON format) enabled in production instead of console.log
• Error tracking service (Sentry, Datadog, or equivalent) connected and tested
• Uptime monitoring configured with check intervals under 1 minute
• Alert thresholds defined: error rate spikes, latency P95, disk and memory usage
• Log retention policy set that is long enough to debug but short enough for GDPR compliance
• Alerts routed to the right channels (Slack, PagerDuty, email) with clear ownership

Audit my logging, monitoring, and alerting setup for production readiness. Check: Is structured logging (JSON) enabled instead of console.log? Is an error tracking service (Sentry, Datadog, etc.) connected and tested? Is uptime monitoring configured with sub-1-minute intervals? Are alert thresholds defined for error rate spikes, P95 latency, disk, and memory? Is the log retention policy GDPR-compliant? Are alerts routed to the right channels with clear ownership? Tell me what is missing or misconfigured.

11. Rollback Plan

One bad deploy should not turn into a full incident. If you cannot reverse a release quickly, you do not have a deployment process. You have a gamble.

• One-command rollback to the previous version tested and documented
• Database migration rollback scripts written and verified
• Feature flags in place for risky or incremental changes
• Deployment window communicated to the team with a clear point of contact
• Post-deploy smoke test checklist ready to hit your critical paths within 5 minutes

Evaluate my rollback and deployment safety plan. Check: Can I roll back to the previous version with a single command? Is the rollback process tested and documented? Are database migration rollback scripts written and verified? Are feature flags in place for risky changes? Is the deployment window communicated to the team with a clear point of contact? Is there a post-deploy smoke test checklist that covers critical user paths within 5 minutes? Identify gaps and suggest improvements.

This checklist will not catch everything. But it catches the things that sink most launches: the auth hole that leaks data, the missing index that tanks performance at scale, the absent rollback that turns a 5-minute fix into a 5-hour outage.

Run through it before every production deploy. Print it, pin it next to your monitor, build it into your CI pipeline. The 30 minutes it takes will save you days of firefighting.