Production Checklist

<!-- Last reviewed: 2026-04-02 | Standards: PCI DSS v4.0, OWASP ASVS v5.0, WCAG 2.2, Google SRE PRR -->

Production Checklist — Automated Codebase Scan

You are a production readiness scanner. On trigger, you scan the codebase and produce a detailed report. Do NOT ask the user to confirm items manually — you verify everything you can from code.

Step 1 — Detect Stack from Files

Glob the project root. Detect all applicable types from file presence:

Tag ALL that apply. Only ask user if truly ambiguous.

No match? If no detection signals match, tell the user: "No supported project type detected. Supported types: web, mobile, api, smart-contract, payment, infrastructure. Run from your project root or specify a type: 'run production checklist for api'."

Monorepos: If the user specifies a subdirectory or package, scope detection and scanning to that subtree. If the root detects 4+ types, ask the user which area to focus on or offer to scan one type at a time.

Step 2 — Load Reference Checklist

Read from references/ adjacent to this file. Only load files matching detected types:

• web → references/web.md
• mobile → references/mobile.md
• api → references/api.md
• smart-contract → references/smart-contract.md
• payment → references/payment.md
• infrastructure → references/infrastructure.md

Deduplication: When loading multiple reference files, some items overlap (e.g., PCI DSS requirements appear in both web.md and payment.md). Deduplicate — report each unique item only once. If a check appears in both files, use the more specific version.

Step 3 — Scan and Verify

For each checklist item, use Glob, Grep, and Read to verify against actual code. Be targeted:

• Grep for specific patterns (secrets, console.log, localStorage, CORS *, missing headers)
• Read config files (package.json, Dockerfile, .gitignore, CI configs, nginx/server configs)
• Glob for file existence (tests, CI pipelines, error pages, health endpoints)

Mark each item:

• ✅ PASS — verified from code (cite file:line)
• ❌ FAIL — violation found (cite file:line) or required thing is missing
• ⚠️ MANUAL — cannot verify from code (DNS, external service config, store listings)

Secret redaction: If you discover actual secrets or credentials, truncate them in the report — show only the first 8 characters followed by ... (e.g., sk_live_a1b2...). Never output full secret values.

Skip items irrelevant to the detected stack. Filter aggressively — a React SPA doesn't need Kubernetes checks.

Step 4 — Produce Report

Output a single, comprehensive report:

╔══════════════════════════════════════╗
║   PRODUCTION READINESS SCAN REPORT  ║
╚══════════════════════════════════════╝

Stack detected: web (Next.js), api (Express), infrastructure (Docker)
Files scanned: N

🔴 CRITICAL
───────────
1. ❌ FAIL — Hardcoded API key in source code
   src/config.ts:14 → const API_KEY = "sk_live_..."
   Fix: Move to .env, add .env* to .gitignore

2. ✅ PASS — HTTPS enforced
   nginx.conf:3 → redirect 301 https://...

3. ⚠️ MANUAL — SSL certificate auto-renewal
   Cannot verify from code — check your hosting provider

🟡 IMPORTANT
────────────
[same format]

🟢 NICE-TO-HAVE
────────────────
[same format]

╔══════════════════════════════════════╗
║            SCORECARD                 ║
╠══════════════════════════════════════╣
║ 🔴 Critical:     12/15 passed       ║
║ 🟡 Important:    18/25 passed       ║
║ 🟢 Nice-to-have:  4/10 passed       ║
╠══════════════════════════════════════╣
║ VERDICT: ⚠️ NOT READY                ║
║ 3 critical blockers must be fixed   ║
╚══════════════════════════════════════╝

BLOCKERS:
1. ❌ Hardcoded API key → src/config.ts:14
2. ❌ No rate limiting → no middleware found
3. ❌ No error tracking → sentry/datadog not in dependencies

Want me to fix these? I can:
• Fix all 3 critical issues now
• Fix a specific one (pick a number)
• Show details for any item

If all critical items pass:

╔══════════════════════════════════════╗
║            SCORECARD                 ║
╠══════════════════════════════════════╣
║ 🔴 Critical:     15/15 passed       ║
║ 🟡 Important:    23/25 passed       ║
║ 🟢 Nice-to-have:  6/10 passed      ║
╠══════════════════════════════════════╣
║ VERDICT: ✅ READY TO SHIP           ║
║ No critical blockers found          ║
╚══════════════════════════════════════╝

Long reports: If total findings exceed 50 items, collapse ✅ PASS items into a count summary (e.g., "14 items passed") and only expand ❌ FAIL and ⚠️ MANUAL items in detail. Offer: "Want me to show all items including passes?"

Step 5 — Fix on Request

When the user asks to fix items, apply actual code changes using Edit/Write. Be concrete — write the real config, middleware, or dependency addition. Don't just describe what to do.

Always show proposed changes before applying. Never commit automatically — let the user review and commit. Never modify files outside the project directory.

Scan Efficiency Rules

1. Structure first: Glob the tree, read manifests — understand the project before deep scanning 2. Targeted greps: Search for specific patterns per checklist item, don't read every file 3. Skip irrelevant types: No Dockerfile? Skip all container items. No *.sol? Skip smart contract. 4. Batch the report: Collect all findings, output once — no streaming item-by-item 5. Prioritize 🔴 Critical: Spend most effort here — these are the ship-blockers 6. Cite evidence: Every PASS/FAIL should reference a file path. This builds trust in the report. 7. Exclude noise directories: Always skip node_modules/, vendor/, .git/, dist/, build/, .next/, __pycache__/ in all Glob and Grep operations

Backend / API Production Checklist

---

🔴 CRITICAL (ship-blockers)

Authentication & Authorization

• [ ] All endpoints require authentication except explicitly public ones (default-deny; whitelist public routes)
• [ ] Machine-to-machine auth uses OAuth 2.0 with mTLS or private_key_jwt — no long-lived static API keys shared over email/Slack
• [ ] JWT access tokens have short expiry ≤ 15 minutes with refresh token rotation (revoke refresh tokens on password change)
• [ ] Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) enforced — principle of least privilege on every endpoint
• [ ] No sensitive data stored in JWT payload — it's Base64-encoded, NOT encrypted (anyone can decode it)
• [ ] Admin/internal endpoints behind separate authentication layer, not just a role check on the same API
• [ ] Password hashing uses bcrypt, scrypt, or Argon2id with appropriate cost factor — never MD5/SHA1/SHA256 for passwords
• [ ] Brute-force protection on login: account lockout or exponential backoff after 5-10 failed attempts
• [ ] Session tokens are invalidated on logout — server-side session store or token blocklist for JWTs
• [ ] Multi-factor authentication (MFA) available for admin and privileged user accounts — enforced for internal tools
• [ ] OAuth/OIDC state parameter validated to prevent CSRF on authorization flows
• [ ] API key scoping: each key has minimum required permissions, IP allowlists where possible, and expiration dates
• [ ] Privilege escalation paths audited — no way for a user to modify their own role or access resources outside their tenant

Input Validation & Injection Prevention

• [ ] All input validated and sanitized server-side — never trust client-side validation alone
• [ ] SQL injection prevented: use parameterized queries or ORM query builders, never string concatenation for SQL
• [ ] NoSQL injection prevented: validate query operators, reject $ prefixed keys in MongoDB user input
• [ ] Request body size limits configured (e.g., body-parser limit, nginx client_max_body_size) to prevent memory exhaustion
• [ ] Content-Type validation on all POST/PUT/PATCH endpoints — reject unexpected content types
• [ ] File upload validation: restrict allowed MIME types, enforce max size, scan for malware, store outside webroot
• [ ] Path traversal prevented: never use user input directly in file system paths (../../../etc/passwd)
• [ ] GraphQL: depth limiting, query complexity analysis, and introspection disabled in production (if applicable)
• [ ] Command injection prevented — never pass user input to shell commands (exec, system, child_process.exec)
• [ ] XML External Entity (XXE) prevention: disable DTD processing and external entity resolution in all XML parsers
• [ ] Server-Side Request Forgery (SSRF) prevented: validate and allowlist URLs when the server makes requests based on user input
• [ ] Mass assignment / over-posting prevented: explicitly whitelist allowed fields on all create/update endpoints (never bind request body directly to model)
• [ ] Regular expression denial of service (ReDoS) prevented: audit all user-facing regex for catastrophic backtracking

Secrets & Configuration

• [ ] No secrets in codebase, Dockerfiles, or container images — scan with git-secrets, truffleHog, or gitleaks
• [ ] Secrets managed via dedicated vault or secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation)
• [ ] Environment-specific configs strictly separated: dev/staging/prod use different databases, keys, and service URLs
• [ ] Database credentials rotated before going to production (don't launch with the same password used during development)
• [ ] Default credentials changed on all services: databases, admin panels, message queues, cache servers
• [ ] .env files excluded from Docker images and Git (verify .gitignore and .dockerignore)
• [ ] Secret rotation automated on a schedule — credentials and API keys rotate without manual intervention or downtime
• [ ] Secrets injected at runtime via environment or mounted volumes — never baked into container images at build time
• [ ] Git history scanned for accidentally committed secrets — rotate any found immediately (they persist in history even after deletion)

Rate Limiting & DoS Protection

• [ ] Rate limiting on all public endpoints with stricter limits on auth routes: login, signup, OTP, password reset (e.g., 5/min for login)
• [ ] WAF (Web Application Firewall) configured in front of the API (Cloudflare, AWS WAF, Fastly) to block common attack patterns
• [ ] Request timeout configured on all routes to prevent slowloris and slow-read attacks (e.g., 30s max)
• [ ] Payload size limits enforced at the reverse proxy / load balancer level as an additional layer
• [ ] API abuse detection: monitor for credential stuffing patterns, automated scraping, enumeration attacks
• [ ] Per-tenant / per-user rate limits for multi-tenant APIs — prevent one tenant from exhausting shared resources
• [ ] Rate limit headers returned to clients: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After

Data Integrity & Transactions

• [ ] All critical mutations wrapped in database transactions with appropriate isolation levels (prevent phantom reads, lost updates)
• [ ] Foreign key constraints and NOT NULL constraints enforced at the database level — never rely solely on application-level validation
• [ ] Idempotency keys required on all payment and financial mutation endpoints — retries must not cause duplicate side effects
• [ ] Unique constraints on business-critical fields (email, username, order ID) enforced at DB level, not just application code
• [ ] Soft delete implemented for user-facing data where recovery may be needed — hard delete only after retention period

---

🟡 IMPORTANT (should fix before launch)

Observability & Monitoring

• [ ] Structured logging in JSON format with consistent fields: timestamp, level, message, correlation_id, service (use pino, winston, structlog, slog)
• [ ] Every request assigned a correlation/trace ID — propagated across service boundaries in headers (e.g., X-Request-ID)
• [ ] Distributed tracing configured if running multiple services (OpenTelemetry, Jaeger, Datadog APM, AWS X-Ray)
• [ ] Four golden signals monitored: latency (p50/p95/p99), traffic (req/s), error rate (%), saturation (CPU/memory/connections)
• [ ] Alerting configured: error rate spike > 1%, p99 latency > threshold, 5xx rate > 0.5% triggers Slack/PagerDuty notification
• [ ] Dashboards created for real-time API health: request volume, error rates, latency percentiles, active connections
• [ ] Log retention configured: logs persist beyond container/pod restarts (ship to Datadog, ELK, Loki, CloudWatch)
• [ ] PII scrubbed from logs — never log passwords, tokens, credit card numbers, SSNs, or full email addresses
• [ ] Health check endpoint implemented: /health for liveness, /ready for readiness (include dependency checks in readiness)
• [ ] SLOs defined for critical user journeys (e.g., 99.9% of login requests complete in < 500ms) — tracked with error budget burn rate alerts
• [ ] Anomaly detection on key metrics — alert on deviation from baseline, not just static thresholds (catches slow degradation)
• [ ] Dependency health monitored — track latency and error rates for every external service call (database, cache, third-party APIs)
• [ ] Audit logging for all privileged actions: admin operations, data exports, permission changes, config modifications (append-only, tamper-evident)

Performance & Scaling

• [ ] Database queries profiled — N+1 queries identified and eliminated (use query logging, Django Debug Toolbar, Prisma query events)
• [ ] Database indexes created for all columns used in WHERE, JOIN, ORDER BY clauses in production query patterns
• [ ] Caching layer configured for hot read paths: Redis, Memcached, or application-level cache with TTL and invalidation strategy
• [ ] API response times validated under load: p50 < 100ms, p99 < 500ms for standard endpoints (run load test before launch)
• [ ] Load test run with realistic traffic patterns and data volume (k6, Artillery, Locust, or Grafana k6 Cloud)
• [ ] Service is stateless — no in-memory session storage, no local file dependencies, can scale horizontally without sticky sessions
• [ ] Database connection pooling configured with appropriate min/max pool sizes (PgBouncer for Postgres; HikariCP for JVM)
• [ ] Pagination implemented on all list endpoints — never return unbounded result sets (use cursor-based pagination for large datasets)
• [ ] Expensive operations offloaded to background jobs/queues (email sending, image processing, report generation)
• [ ] Database has read replicas configured for read-heavy workloads (if applicable — confirm replication lag is acceptable)
• [ ] Query result caching with cache invalidation strategy — avoid thundering herd on cache expiry (use stale-while-revalidate or locking)
• [ ] Slow query log enabled — queries exceeding threshold (e.g., > 200ms) are logged and reviewed regularly
• [ ] Auto-scaling policies configured and tested — service scales out under load and scales in during low traffic (verify both directions)
• [ ] Connection limits set on all external dependencies — prevent a single tenant or burst from exhausting connection pools

Reliability & Resilience

• [ ] Graceful shutdown handling: drain in-flight requests on SIGTERM, close database connections cleanly (critical for zero-downtime deploys)
• [ ] Retry logic with exponential backoff and jitter for external service calls — never retry on 4xx client errors except 429 Too Many Requests (which should be retried after Retry-After delay)
• [ ] Circuit breaker pattern implemented for critical external dependencies (prevent cascade failures)
• [ ] Database migration rollback tested — can you reverse the latest migration without data loss?
• [ ] Automated database backup schedule configured and restore procedure tested at least once (verify backups are not corrupted)
• [ ] Timeouts configured for all external HTTP calls, database queries, and queue operations (default unlimited timeout = memory leak risk)
• [ ] Dead letter queues configured for failed async jobs — failed messages are not silently dropped
• [ ] Bulkhead pattern implemented — failures in non-critical services don't bring down critical paths (isolate thread pools/connection pools)
• [ ] Graceful degradation configured — if a dependency is down, serve cached/default data instead of failing entirely
• [ ] Leader election or distributed locking in place for operations that must run on exactly one instance (cron jobs, migrations, queue consumers)
• [ ] Poison message handling — malformed messages in queues are detected and routed to DLQ after max retries, not retried infinitely
• [ ] RTO and RPO defined for each data store — backup frequency and failover time align with business requirements

Data Management & Compliance

• [ ] Database schema versioned with migration tool (Flyway, Alembic, Prisma Migrate, Knex) — never apply DDL manually in production
• [ ] Schema migrations are backward-compatible — old app version can run against new schema during rolling deploy (expand-then-contract pattern)
• [ ] Data retention policies defined and automated — PII is purged or anonymized after retention period expires
• [ ] GDPR compliance: right to access (data export), right to erasure (data deletion), right to portability implemented
• [ ] CCPA compliance: "Do Not Sell" opt-out mechanism, data disclosure on request, deletion on request
• [ ] Data classification applied — PII, financial data, health data (PHI) identified and protected with appropriate encryption and access controls
• [ ] Data anonymization or pseudonymization applied to non-production environments — never use real user data in staging/dev
• [ ] Cross-border data transfer compliance verified — data residency requirements met for EU (GDPR), China (PIPL), etc.
• [ ] Data backup encryption enabled — backups are encrypted at rest and access-controlled independently from production data
• [ ] Soft-delete and data recovery workflow tested — accidentally deleted data can be restored within the retention window
• [ ] Database connection encryption enforced — TLS required for all database connections (no plaintext database traffic)

Documentation & Operations

• [ ] OpenAPI / Swagger spec is up-to-date and matches actual API behavior (auto-generate from code where possible)
• [ ] Runbooks written for top 5 most likely incidents: database full, service down, spike in errors, memory leak, dependency outage
• [ ] On-call rotation assigned — someone is responsible for production issues and knows how to respond
• [ ] Incident response plan documented: who gets paged, escalation path, communication channel, postmortem process
• [ ] Service ownership documented: team name, Slack channel, PagerDuty policy, repo link
• [ ] API changelog maintained for breaking changes — consumers know what changed and when
• [ ] Architecture decision records (ADRs) maintained for significant technical decisions (why, alternatives considered, trade-offs) — especially for data store choices, protocol decisions, and security architecture
• [ ] Dependency map documented — all upstream and downstream services, databases, queues, and third-party APIs visualized
• [ ] Capacity planning reviewed — current resource utilization documented with projections for 6-12 months growth
• [ ] Postmortem template and process defined — blameless postmortems required for all SEV1/SEV2 incidents within 48 hours

Security (continued)

• [ ] TLS 1.2+ enforced on all endpoints; TLS 1.0 and 1.1 disabled (check with SSL Labs test)
• [ ] Sensitive data encrypted at rest: PII, financial data, health data (AES-256-GCM or platform-managed encryption)
• [ ] SAST (Static Application Security Testing) scan run with zero critical/high findings unresolved (Snyk, Semgrep, CodeQL)
• [ ] Dependency vulnerabilities audited — no critical CVEs in production dependencies (npm audit, pip audit, cargo audit, go vuln check)
• [ ] CORS policy explicitly configured with allowed origins list — never Access-Control-Allow-Origin: * on authenticated APIs
• [ ] Security headers set: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy
• [ ] API responses don't leak internal details: no stack traces, no framework version headers, no database error messages in 5xx responses
• [ ] DAST (Dynamic Application Security Testing) scan run against staging environment — OWASP ZAP or Burp Suite with zero critical findings
• [ ] Container images scanned for vulnerabilities (Trivy, Snyk Container, Grype) — base images updated to latest patched versions
• [ ] Least privilege IAM roles for all cloud resources — no wildcards (*) in production IAM policies
• [ ] Network segmentation enforced — databases and internal services not accessible from the public internet (private subnets, security groups)
• [ ] API authentication bypass tested — pen test confirms no endpoint is accessible without valid credentials
• [ ] Supply chain security: signed commits, verified base images, SBOM (Software Bill of Materials) generated for production artifacts

Distributed Systems (if microservices)

• [ ] Service discovery configured and tested — services can find each other without hardcoded addresses (Consul, Kubernetes DNS, AWS Cloud Map)
• [ ] Distributed tracing spans cover the full request lifecycle across all services (OpenTelemetry collector deployed)
• [ ] Inter-service communication secured with mTLS or service mesh (Istio, Linkerd, Consul Connect)
• [ ] Event-driven communication uses durable message broker (Kafka, RabbitMQ, SQS) — not direct HTTP calls for async workflows
• [ ] Contract testing between services — producer and consumer contracts verified in CI (Pact, Specmatic)
• [ ] Saga pattern or compensating transactions implemented for distributed workflows that span multiple services
• [ ] Service mesh traffic policies configured: retries, timeouts, circuit breakers, and canary routing at the mesh level
• [ ] Cross-service schema compatibility verified — Protobuf/Avro schema registry enforces backward compatibility for event schemas

---

🟢 NICE-TO-HAVE (polish)

• [ ] API versioning strategy implemented and documented (/v1/, header-based, or query param — pick one and be consistent)
• [ ] Canary deployment or blue-green deployment configured for zero-downtime releases
• [ ] Server-side feature flags integrated for safe rollouts and instant kill switches (LaunchDarkly, Flagsmith, Unleash, or config-based)
• [ ] Idempotency keys supported on all mutation endpoints (not just payments — any POST that creates resources)
• [ ] Webhook delivery includes retry with exponential backoff and HMAC signature verification for consumers
• [ ] Shadow traffic / traffic replay testing (GoReplay) run before major refactors to compare old vs new behavior
• [ ] Request/response examples in OpenAPI spec for every endpoint (improves developer experience for API consumers)
• [ ] Chaos engineering: tested behavior under dependency failure, network partition, high latency (Chaos Monkey, Litmus, Toxiproxy)
• [ ] Automated canary analysis: new deployments are auto-rolled-back if error rate or latency degrades vs baseline
• [ ] Data migration scripts are idempotent and can be re-run safely
• [ ] API deprecation strategy documented: how much notice, sunset headers, migration guides for consumers
• [ ] GraphQL persisted queries or query allowlisting for production (prevent arbitrary query abuse)
• [ ] Cost allocation tags on all cloud resources — team/service/environment traceable for FinOps
• [ ] Synthetic monitoring: automated tests simulate key user journeys from multiple regions every N minutes (Checkly, Datadog Synthetics)
• [ ] Request tracing includes business context (user ID, tenant ID, feature flag state) for debugging production issues
• [ ] Database query plan analysis automated — CI warns when a migration introduces a sequential scan on large tables
• [ ] Multi-region failover tested — traffic routes to secondary region within RTO if primary region goes down
• [ ] Write-ahead logging or event sourcing for critical business operations — enables audit trail and temporal queries
• [ ] gRPC or binary protocol used for high-throughput internal service communication (lower overhead than JSON over HTTP)
• [ ] API gateway configured for cross-cutting concerns: auth, rate limiting, request transformation, response caching (Kong, Apigee, AWS API Gateway)

Infrastructure & SRE Production Checklist

---

🔴 CRITICAL (ship-blockers)

Infrastructure as Code (IaC)

• [ ] All infrastructure defined in code — Terraform, Pulumi, CloudFormation, or CDK (no manual console-created resources in production)
• [ ] IaC state stored remotely with locking (Terraform: S3 + DynamoDB lock; Pulumi: Pulumi Cloud or S3 backend)
• [ ] Infrastructure CI/CD pipeline: plan on PR, apply on merge to main — no terraform apply from developer laptops
• [ ] Drift detection automated — alert when actual infrastructure deviates from IaC state (scheduled terraform plan or CloudFormation drift detection)
• [ ] IaC modules versioned and pinned — no latest tags or unpinned module sources in production
• [ ] Secrets and credentials NEVER in IaC code or state files — use secrets manager references or encrypted variables
• [ ] Destructive changes require approval — resource deletion or replacement gated by policy (Terraform prevent_destroy, OPA policies, or manual approval step)
• [ ] Disaster recovery: infrastructure can be fully recreated from IaC in a new region/account within documented RTO

Compute & Container Orchestration

• [ ] Container images use minimal base images (distroless, Alpine, or scratch) — no full OS distributions in production
• [ ] Container images scanned for vulnerabilities in CI pipeline (Trivy, Snyk, Grype) — zero critical/high CVEs before deploy
• [ ] Container images are immutable and tagged with Git SHA — no latest tag in production deployments
• [ ] Resource requests and limits set on all containers: CPU and memory requests defined, memory limits set (CPU limits are optional — omitting them avoids throttling, but set them if you need predictable multi-tenant isolation)
• [ ] Pod disruption budgets (PDB) configured for all production workloads — ensure minimum available replicas during node maintenance
• [ ] Horizontal Pod Autoscaler (HPA) configured and tested: scales out under load, scales in during low traffic (verify both directions)
• [ ] Liveness and readiness probes configured on all containers — readiness includes dependency health checks
• [ ] No containers run as root — runAsNonRoot: true in security context, readOnlyRootFilesystem: true where possible
• [ ] Pod anti-affinity rules ensure replicas spread across nodes/zones — no single node failure takes down all replicas
• [ ] Graceful shutdown: containers handle SIGTERM, drain connections within terminationGracePeriodSeconds
• [ ] Init containers handle dependency ordering — don't rely on service readiness for startup sequence
• [ ] Container registry access controlled — only CI/CD pipeline can push images, production cluster pulls with read-only credentials

Networking & Load Balancing

• [ ] Load balancer configured with health checks — unhealthy backends are automatically removed from rotation
• [ ] TLS termination at load balancer or ingress with managed certificates (AWS ACM, Let's Encrypt, Google-managed certs)
• [ ] Network segmentation enforced: databases and internal services in private subnets, not accessible from the internet
• [ ] Firewall rules / security groups follow least privilege — only required ports open, source IPs restricted
• [ ] DNS TTL set appropriately: low TTL (60-300s) for services that may failover, higher TTL for stable endpoints
• [ ] DDoS protection enabled at the edge (Cloudflare, AWS Shield, Google Cloud Armor)
• [ ] Internal service communication encrypted with mTLS or within a VPC/private network — no plaintext traffic between services
• [ ] Egress filtering configured — production workloads can only reach explicitly allowed external endpoints
• [ ] IPv6 support tested if enabled — no broken connectivity for IPv6-only clients

Identity & Access Management (IAM)

• [ ] Root / super-admin account secured with MFA and hardware key — never used for day-to-day operations
• [ ] Least privilege IAM policies: no wildcard (*) permissions in production — each service has a scoped role
• [ ] Service accounts / instance roles used for machine-to-machine auth — no long-lived access keys
• [ ] IAM access reviewed quarterly: remove stale users, reduce over-provisioned permissions
• [ ] Break-glass procedure documented: emergency access path when normal auth is unavailable (documented, audited, alarmed)
• [ ] SSO enforced for all team access to cloud console and internal tools (Okta, Azure AD, Google Workspace)
• [ ] Cloud API audit logging enabled and monitored (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) — alert on suspicious activity
• [ ] Temporary credentials used wherever possible — AWS STS AssumeRole, GCP Workload Identity, Azure Managed Identity

Secrets Management

• [ ] Centralized secrets manager deployed: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault
• [ ] Secrets injected at runtime — never baked into container images, config maps, or Helm values
• [ ] Secret rotation automated on schedule — database credentials, API keys, TLS certificates rotate without downtime
• [ ] Secret access audited — every read/write to secrets manager is logged with actor identity and timestamp
• [ ] Encryption keys managed with KMS — customer-managed keys for sensitive workloads, key rotation enabled
• [ ] Secrets never appear in CI/CD logs — pipeline tools configured to mask/redact secret values in output

---

🟡 IMPORTANT (should fix before launch)

Observability & Monitoring

• [ ] Three pillars configured: structured logs (ELK, Loki, CloudWatch), metrics (Prometheus, Datadog, CloudWatch), traces (OpenTelemetry, Jaeger)
• [ ] OpenTelemetry Collector deployed as DaemonSet or sidecar — vendor-agnostic telemetry pipeline
• [ ] SLOs defined for critical user journeys: availability and latency targets with error budget tracking
• [ ] Error budget burn rate alerts: fast-burn (> 10x) pages immediately, slow-burn (> 2x) creates ticket
• [ ] Four golden signals monitored for every service: latency, traffic, error rate, saturation
• [ ] Infrastructure metrics collected: CPU, memory, disk, network for all nodes — alert on saturation (> 80% sustained)
• [ ] Log aggregation configured: all container/pod logs shipped to central store with retention policy (30 days hot, 90 days warm, 1 year cold)
• [ ] PII scrubbed from all logs and traces before ingestion — automated redaction rules for emails, tokens, card numbers
• [ ] Dashboards created: service health overview, infrastructure utilization, deployment tracker, error rate trends
• [ ] Alerting hierarchy defined: SEV1 → pages on-call, SEV2 → Slack notification, SEV3 → ticket created — no alert fatigue
• [ ] Synthetic monitoring: automated tests simulate critical user journeys from multiple geographic regions every 5 minutes
• [ ] Cost monitoring dashboards: per-service and per-team cost allocation tracked with anomaly alerts for unexpected spend

Deployment & Release

• [ ] CI/CD pipeline fully automated: commit → build → test → scan → deploy to staging → deploy to production
• [ ] Deployment strategy configured: rolling update, blue-green, or canary — never stop-the-world deploys
• [ ] Canary deployments for critical services: route 5% traffic to new version, monitor for 15 minutes, then expand
• [ ] Automated rollback: deployment auto-reverts if error rate or latency exceeds threshold during canary phase
• [ ] Deployment frequency tracked — aim for multiple deploys per day with confidence (DORA metric)
• [ ] Rollback tested and documented: team can revert to previous version within 5 minutes (one-click rollback)
• [ ] Database migrations decoupled from application deploys — run expand phase before deploy, contract phase after
• [ ] Feature flags used for risky changes — deploy dark code, enable gradually, kill instantly if needed
• [ ] Deployment notifications sent to team channel: who deployed what, when, with link to diff and rollback
• [ ] Artifact promotion: same build artifact progresses from staging → production (no rebuild for production)
• [ ] Deploy freeze process defined: how to pause deployments during incidents, holidays, or high-traffic events

Disaster Recovery & Business Continuity

• [ ] RTO (Recovery Time Objective) and RPO (Recovery Point Objective) defined per service tier — documented and agreed with business
• [ ] Database backups automated and tested: backup runs on schedule, restore procedure tested quarterly
• [ ] Backup encryption enabled — backups encrypted at rest with separate key from production data
• [ ] Cross-region replication configured for critical data stores — failover region can serve traffic within RTO
• [ ] Disaster recovery runbook documented: step-by-step failover procedure with decision tree and responsible parties
• [ ] DR drill conducted at least annually — full failover to secondary region with timing measured against RTO/RPO
• [ ] Backup retention policy defined and automated: daily (30 days), weekly (12 weeks), monthly (12 months) — or per compliance requirements
• [ ] Point-in-time recovery (PITR) enabled for critical databases — can restore to any second within retention window
• [ ] Multi-AZ deployment for all stateful services — database, cache, message queue survive single-AZ failure
• [ ] Failback procedure documented and tested — how to restore operations to primary region after DR event
• [ ] Chaos testing conducted: randomly kill instances, inject network latency, fail a dependency — verify graceful degradation (Chaos Monkey, Gremlin, Litmus)

Capacity Planning & Scaling

• [ ] Current resource utilization baselined: CPU, memory, disk, connections, IOPS for all production services
• [ ] Growth projections documented: expected traffic growth for next 6-12 months with scaling plan
• [ ] Auto-scaling tested under load: verify scale-out triggers, scale-in cooldown, and maximum instance limits
• [ ] Database capacity planned: storage growth rate, connection pool limits, read replica needs for projected traffic
• [ ] Rate limits calibrated to actual capacity — reject requests gracefully before system saturates
• [ ] Load test run with 2-3x expected peak traffic — identify bottlenecks before they hit production (k6, Locust, Gatling)
• [ ] Quotas and limits set on cloud resources — prevent runaway costs from auto-scaling bugs or resource leaks
• [ ] Queue depth monitoring with auto-scaling: worker pools scale based on queue backlog
• [ ] Capacity review scheduled quarterly — update projections, adjust resources, plan for upcoming events (seasonal traffic)

Reliability & Resilience Patterns

• [ ] Circuit breakers configured for all external dependencies — prevent cascade failures when a dependency is down
• [ ] Retry policies with exponential backoff and jitter for all external calls — no retry storms during outages
• [ ] Bulkhead pattern: separate thread/connection pools for critical vs non-critical dependencies
• [ ] Timeout budgets: every external call has an explicit timeout, request-level timeout budget propagated across service chain
• [ ] Graceful degradation: if non-critical dependency fails, serve reduced functionality instead of 500 errors
• [ ] Rate limiting at service mesh / API gateway level — protect backend services from traffic spikes
• [ ] Data replication lag monitored for read replicas — alert if lag exceeds acceptable threshold for use case
• [ ] Leader election / distributed locks for singleton workloads (cron jobs, migration runners) — tested for split-brain scenarios
• [ ] Connection draining on shutdown: load balancer stops sending new requests, existing requests complete within grace period

Incident Management & On-Call

• [ ] On-call rotation established with primary and secondary — rotation is fair, documented, and compensated
• [ ] Escalation policy defined: if primary doesn't acknowledge within 5 minutes, page secondary, then management
• [ ] Incident response process documented: detection → triage → mitigation → communication → resolution → postmortem
• [ ] Severity levels defined with examples: SEV1 (total outage), SEV2 (degraded for subset), SEV3 (minor impact), SEV4 (no user impact)
• [ ] Communication template ready: status page update, customer notification, internal Slack message — pre-written for common scenarios
• [ ] Status page configured and maintained (Statuspage.io, Instatus, Cachet) — auto-updated by monitoring where possible
• [ ] Incident communication channel auto-created on page (Slack channel, Zoom bridge) with context pinned
• [ ] Runbooks written for top 10 most likely incidents — step-by-step with commands, not just descriptions
• [ ] Blameless postmortem process: required for all SEV1/SEV2 within 48 hours, action items tracked to completion
• [ ] On-call handoff process: outgoing on-call documents active issues, pending deployments, known risks for incoming on-call
• [ ] Game days scheduled quarterly: simulate production failures and practice incident response (tabletop exercises at minimum)

Security & Compliance Infrastructure

• [ ] Vulnerability scanning automated in CI/CD: SAST, DAST, container scanning, dependency scanning — zero critical before deploy
• [ ] Runtime security monitoring: detect anomalous process execution, file access, network connections in production containers (Falco, Aqua, Prisma Cloud)
• [ ] Network intrusion detection / prevention system (IDS/IPS) in place for production network segments
• [ ] WAF rules tuned and updated: OWASP Core Rule Set active, custom rules for application-specific patterns
• [ ] Immutable infrastructure: production instances are never patched in place — replace with new image containing patches
• [ ] OS and runtime patches applied within SLA: critical CVEs within 24 hours, high within 7 days, medium within 30 days
• [ ] SOC 2 Type II controls documented and evidenced if B2B SaaS (or equivalent compliance framework for your industry)
• [ ] Data classification policy applied to infrastructure: tag resources by data sensitivity level (public, internal, confidential, restricted)
• [ ] Encryption at rest enabled for all data stores: databases, object storage, EBS volumes, backups — using KMS-managed keys
• [ ] Encryption in transit enforced everywhere: TLS for all external traffic, mTLS or VPC for internal traffic
• [ ] Audit logging for infrastructure changes: who created/modified/deleted what resource, when, from which IP
• [ ] SBOM (Software Bill of Materials) generated for all production artifacts — enables rapid response to zero-day CVEs

Documentation & Operations

• [ ] Architecture diagram up-to-date: services, data stores, message queues, external dependencies, network boundaries
• [ ] Service catalog maintained: every production service listed with owner, repo, runbook, SLO, dependencies, on-call team
• [ ] Architecture Decision Records (ADRs) maintained for all significant infrastructure decisions
• [ ] Dependency map visualized: understand which services depend on which, identify single points of failure
• [ ] Change management process defined: how changes are proposed, reviewed, approved, and rolled back
• [ ] Toil budget tracked: measure and reduce repetitive manual operational work (target < 50% of SRE time on toil per Google SRE book)
• [ ] Knowledge base maintained: troubleshooting guides, FAQ, common issues and resolutions

---

🟢 NICE-TO-HAVE (polish)

• [ ] GitOps adopted: ArgoCD or Flux for Kubernetes manifest deployment — cluster state driven from Git
• [ ] Policy as code: OPA/Gatekeeper, Kyverno, or Sentinel policies enforce security and compliance in CI/CD and cluster
• [ ] Service mesh deployed (Istio, Linkerd, Consul Connect) for mTLS, traffic management, and observability across services
• [ ] FinOps practices: reserved instances/savings plans for baseline, spot/preemptible for burst, per-team cost allocation
• [ ] Multi-cloud or multi-region active-active: traffic served from multiple regions/clouds with automatic failover
• [ ] Cluster autoscaler tuned: nodes scale based on pending pod resource requests, scale-down after cooldown period
• [ ] Ephemeral environments: spin up full stack per PR for testing, tear down on merge (Terraform workspaces, Argo CD ApplicationSets)
• [ ] Progressive delivery: Argo Rollouts or Flagger for automated canary analysis with metric-driven promotion
• [ ] Cost anomaly detection: alert when daily spend deviates > 20% from 7-day average
• [ ] Infrastructure testing: Terratest, Checkov, or terraform validate in CI — catch misconfigurations before apply
• [ ] Centralized certificate management: auto-provisioned and auto-renewed TLS certificates (cert-manager with Let's Encrypt)
• [ ] Log-based alerting: detect specific error patterns in logs and create alerts (Loki alerting rules, CloudWatch Insights)
• [ ] Observability-as-code: dashboards, alerts, and SLO definitions version-controlled alongside application code (Terraform, Crossplane)
• [ ] Internal developer platform: self-service infrastructure provisioning with guardrails (Backstage, Port, Cortex)
• [ ] Kubernetes namespace isolation: resource quotas, network policies, and RBAC per namespace/team
• [ ] Image signing and verification: Sigstore/Cosign for supply chain security — only signed images run in production
• [ ] Preemptible/spot instance strategy: non-critical workloads run on spot with graceful interruption handling
• [ ] Database schema change management: automated review of migration impact (query plan analysis, lock detection)
• [ ] Distributed tracing with business context: inject user ID, tenant ID, feature flags into trace spans for debugging
• [ ] Operational readiness review (ORR) gate: new services must pass production readiness checklist before first deploy

Mobile App Production Checklist (iOS & Android)

---

🔴 CRITICAL (ship-blockers)

App Store / Play Store Compliance

• [ ] iOS: App built with latest required Xcode version, targeting current minimum iOS SDK (check Apple's current deadline)
• [ ] Android: App targets the current required API level — new apps on Play Store must target latest stable API
• [ ] Android: App distributed as .aab (Android App Bundle), NOT legacy APK (required by Play Store)
• [ ] Privacy policy URL is live, accessible, and linked in both App Store Connect and Play Console store listings
• [ ] All requested permissions have user-facing justification strings (iOS: every NS...UsageDescription key in Info.plist; Android: runtime permission rationale)
• [ ] Only permissions actually used by the app are requested — remove any leftover/unused permission declarations
• [ ] Demo/test account credentials prepared and entered for App Store reviewers (required if app has login — rejection guaranteed without this)
• [ ] App Review Guidelines compliance verified: no private/undocumented API usage (iOS), no external payment links for digital goods (both platforms)
• [ ] AI/ML transparency disclosure added if app uses generative AI, LLMs, or external AI services (Apple & Google require disclosure)
• [ ] Login with Apple implemented if app offers any third-party social login (Apple requirement since 2020)
• [ ] App does not crash on launch or during primary flow — test the exact binary being submitted, not a debug build
• [ ] No placeholder content, test data, or "lorem ipsum" visible anywhere in the app
• [ ] EU Digital Markets Act (DMA) compliance: alternative payment options and sideloading disclosures if distributing in the EU (iOS 17.4+)
• [ ] App content rating accurate and matches store questionnaire responses — incorrect rating leads to removal

Code Signing & Build Configuration

• [ ] iOS: Production distribution certificate and provisioning profile configured (not development/ad-hoc)
• [ ] Android: Release keystore created, backed up securely, and NOT committed to Git (losing the keystore = cannot update the app)
• [ ] Bundle ID / Application ID is unique, correctly formatted, and matches App Store Connect / Play Console entry
• [ ] Version number (CFBundleShortVersionString / versionName) and build number (CFBundleVersion / versionCode) incremented from last submission
• [ ] Release build tested on physical devices — not just emulator/simulator (test on oldest supported device you own)
• [ ] ProGuard / R8 code shrinking enabled for Android release builds (minifyEnabled true) — test that obfuscation doesn't break reflection/serialization
• [ ] Bitcode, dSYM, or debug symbols uploaded for crash symbolication (or configured to auto-upload via Crashlytics/Sentry)
• [ ] CI/CD pipeline builds, signs, and distributes the release binary — no manual builds from developer machines
• [ ] Build reproducibility verified — same commit produces same binary (pin dependency versions, lock files committed)

Security

• [ ] No API keys, secrets, tokens, or credentials hardcoded in source code or bundled in the app binary (extract with strings to verify)
• [ ] Sensitive API calls use certificate pinning or at minimum TLS 1.2+ (prevent MITM on public WiFi)
• [ ] User credentials and tokens encrypted at rest (iOS: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly; Android: EncryptedSharedPreferences or Keystore)
• [ ] App Transport Security (ATS) is NOT globally disabled on iOS (NSAllowsArbitraryLoads must be false in production)
• [ ] Jailbreak/root detection implemented if app handles payments, banking, or sensitive health/financial data
• [ ] Sensitive screens disable screenshots/screen recording where required (iOS: window overlay; Android: FLAG_SECURE)
• [ ] Biometric authentication (Face ID/Touch ID, Android BiometricPrompt) used for sensitive actions if applicable
• [ ] No sensitive data written to application logs — NSLog / Log.d must never contain tokens, passwords, PII
• [ ] Local database (SQLite, Realm, Core Data) encrypted if storing sensitive user data (SQLCipher, Realm encryption)
• [ ] Clipboard cleared after sensitive copy operations (e.g., OTP codes) — UIPasteboard.general.setItems([], options: [.expirationDate: Date()]))
• [ ] Binary is obfuscated — reverse engineering of app logic is not trivially easy (iOS: Swift obfuscation; Android: R8 with proguard-rules)
• [ ] Deep link handlers validate all parameters — no injection attacks via myapp://path?param=malicious_value
• [ ] WebView content is sandboxed — WKWebView with javaScriptEnabled: false where not needed, no evaluateJavaScript with user input
• [ ] Network security config (Android) restricts cleartext traffic and pins certificates for production domains

---

🟡 IMPORTANT (should fix before launch)

Testing

• [ ] Tested on the minimum supported OS version declared in store listing (install on an old device or use Xcode/Android simulators)
• [ ] Tested across screen sizes: small (iPhone SE / Android compact), standard, large (Pro Max / tablet)
• [ ] Background → foreground transitions tested — no crash, stale data, or blank screen on app resume
• [ ] Push notifications tested end-to-end: delivery, display, tap → deep link to correct screen, permission prompt UX
• [ ] Offline state handled gracefully — show cached data or clear "no connection" message, never blank/frozen screens
• [ ] Network transitions tested: WiFi → cellular, cellular → offline, slow 3G simulation (use Network Link Conditioner / Charles Proxy)
• [ ] Memory pressure handling tested (iOS: didReceiveMemoryWarning; monitor with Instruments/Profiler for leaks)
• [ ] Deep links / universal links tested: tapping a link from email/browser opens the correct screen in the app
• [ ] App handles interrupted flows: incoming call during payment, backgrounded during upload, permission denied mid-flow
• [ ] Accessibility tested: VoiceOver (iOS) and TalkBack (Android) can navigate all primary flows
• [ ] Landscape orientation handled or explicitly locked to portrait (no half-rendered layouts)
• [ ] Force-kill and relaunch: app recovers state correctly, no data loss for in-progress work
• [ ] Concurrent session handling tested — what happens when user logs in on a second device? (session invalidation, data sync)
• [ ] Time zone and locale changes tested — app handles users traveling across time zones without data corruption
• [ ] Large data set handling tested — lists with 10,000+ items scroll smoothly (virtual list / recycler view implemented)
• [ ] App behavior tested when storage is nearly full — handle write failures gracefully, not crash

Store Listing & ASO (App Store Optimization)

• [ ] App icon: 1024×1024px PNG, no transparency/alpha channel (iOS strict requirement); 512×512px hi-res icon (Android)
• [ ] Screenshots prepared for all required device sizes (iOS: 6.7", 6.5", 5.5" at minimum; Android: phone + 7" + 10" tablet if supporting)
• [ ] App preview video prepared — 15-30 seconds showing core value prop (optional but significantly boosts conversion)
• [ ] App name/title optimized: ≤ 30 chars (Android) / ≤ 50 chars (iOS) — include primary search keyword
• [ ] Short description ≤ 80 chars (Android) — this is the most-read copy in the Play Store listing
• [ ] Full description keyword-optimized and clearly explains what the app does in the first 2 lines (most users don't expand)
• [ ] Content rating questionnaire completed accurately (wrong rating = removal risk)
• [ ] App category and subcategory chosen strategically (affects browse discoverability)
• [ ] What's New / Release Notes written — describe changes users care about, not internal refactors
• [ ] Subtitle (iOS) / Short description (Android) includes secondary keyword not in the title

Performance & Monitoring

• [ ] Crash reporting SDK configured and verified — crashes appear in dashboard (Firebase Crashlytics, Sentry, Bugsnag)
• [ ] Analytics events tracking core funnel: app open, signup, key feature usage, purchase (Firebase Analytics, Amplitude, Mixpanel)
• [ ] App binary size optimized: < 50MB preferred for over-the-air install (use App Thinning on iOS; bundletool analysis on Android)
• [ ] Battery usage profiled — no excessive background CPU, GPS, or network drain (use Instruments Energy Log / Android Battery Profiler)
• [ ] Cold start time < 2 seconds on mid-range devices (profile with Instruments / Android Profiler; defer heavy init)
• [ ] Memory usage stays under 200MB during normal use (monitor for leaks with Instruments / LeakCanary)
• [ ] Network requests are efficient: batch where possible, paginate lists, compress payloads (gzip/brotli)
• [ ] Images and assets loaded at appropriate resolution for device screen density (@2x/@3x; mdpi through xxxhdpi)
• [ ] ANR (Application Not Responding) rate monitored on Android — keep below 0.47% (Play Console vitals threshold)
• [ ] Startup trace captured — no blocking I/O on main thread during app launch (use async init, lazy loading)
• [ ] Render performance profiled — UI runs at 60fps, no jank during scrolling or animations (use GPU profiler)
• [ ] Background fetch and sync optimized — respect system-imposed limits (iOS Background App Refresh, Android WorkManager constraints)

Compliance & Legal

• [ ] GDPR compliance: App Tracking Transparency (ATT) prompt shown on iOS 14.5+ before any tracking/advertising ID access
• [ ] CCPA compliance if serving California users: "Do Not Sell My Personal Information" option available if applicable
• [ ] Google Play Data Safety section filled out accurately (required — app will be flagged without it)
• [ ] Apple App Privacy nutrition labels filled out in App Store Connect (required — submission blocked without it)
• [ ] In-app purchases use platform IAP system for digital goods — no links to external payment (Apple/Google policy, enforced)
• [ ] Account deletion feature available if app offers account creation (Apple hard requirement; Google Play policy)
• [ ] Children's/COPPA compliance reviewed if app could attract under-13 users (age gate, restricted data collection)
• [ ] Data retention and deletion policies documented — user data is deletable upon request
• [ ] Third-party SDK privacy policies reviewed — ensure every SDK included is compliant with your privacy commitments
• [ ] Data collection consent granular — users can opt in/out of specific data categories (analytics, crash reports, personalization)
• [ ] Health data handling compliant if applicable (Apple HealthKit guidelines, HIPAA for US health apps)

Payments & In-App Purchases (if applicable)

• [ ] In-app purchase products created and approved in App Store Connect / Play Console (subscription or consumable)
• [ ] Purchase flow handles all StoreKit 2 / Google Billing Library edge cases: pending transactions, deferred purchases, family sharing
• [ ] Receipt validation performed server-side — never trust client-side receipt validation (trivially bypassable)
• [ ] Subscription status synced with server — handle renewals, cancellations, grace periods, billing retry
• [ ] Restore purchases flow works correctly — users who reinstall or switch devices can recover their purchases
• [ ] Free trial and introductory offer terms clearly displayed before purchase (App Store requirement)
• [ ] Subscription management link provided — users can easily find where to cancel (required by both platforms)
• [ ] Refund handling implemented — server is notified of App Store/Play Store refunds and revokes access appropriately
• [ ] Price localization configured — prices set per region in store dashboard (not converted at runtime)
• [ ] Entitlement checks use server-side truth — don't rely solely on cached purchase state on device

Accessibility (a11y)

• [ ] VoiceOver (iOS) and TalkBack (Android) fully navigate all screens — no unlabeled buttons or inaccessible content
• [ ] Dynamic Type (iOS) and font scaling (Android) supported — text scales up to 200% without clipping or overlapping (iOS: use system text styles; Android: use sp units)
• [ ] Color contrast meets WCAG AA: 4.5:1 for normal text, 3:1 for large text
• [ ] Touch targets ≥ 44×44pt (iOS) / 48×48dp (Android) — platform minimum sizes for accessibility
• [ ] Screen reader announcements for dynamic content changes (new messages, loading states, errors)
• [ ] Custom gestures have accessible alternatives — swipe-to-delete must have a button alternative
• [ ] Switch Control (iOS) and Switch Access (Android) can navigate primary flows

---

🟢 NICE-TO-HAVE (polish)

• [ ] App Clip (iOS) or Instant App (Android) configured for lightweight trial experience without full install
• [ ] Localization for target markets: all user-facing strings externalized in .strings / strings.xml / ARB files
• [ ] Dark mode fully supported and tested (iOS: @Environment(\.colorScheme); Android: isNightMode)
• [ ] Home screen widgets configured for quick-glance information (WidgetKit on iOS; AppWidgetProvider on Android)
• [ ] Store listing A/B experiments set up in Google Play Console (test icon, screenshots, descriptions)
• [ ] In-app review prompt implemented at a moment of delight, not on first launch (StoreKit requestReview / Play In-App Review API)
• [ ] Force-update mechanism: remotely require users on critically broken versions to update (use Firebase Remote Config or custom API)
• [ ] Feature flags / remote config integrated for safe rollouts and kill switches (Firebase Remote Config, LaunchDarkly)
• [ ] Onboarding flow tested for first-time users — clear value prop, minimal friction to core experience
• [ ] Haptic feedback used thoughtfully for key interactions (success, error, selection)
• [ ] Adaptive icons configured for Android (foreground + background layers for consistent shape across launchers)
• [ ] iPad / tablet layout optimized if supporting larger screens (not just phone layout stretched)
• [ ] Staged rollout configured — release to 5% → 25% → 100% of users (Play Console staged rollout / TestFlight phased release)
• [ ] Crash-free rate target > 99.5% monitored before each rollout expansion
• [ ] Offline-first architecture: local database syncs with server when connectivity resumes (CRDT or last-write-wins)
• [ ] Background upload/download with progress tracking — survives app backgrounding (URLSession background task / WorkManager)
• [ ] App shortcuts configured (iOS: Quick Actions from 3D Touch/Haptic Touch; Android: App Shortcuts)
• [ ] Share extension or share sheet integration for receiving content from other apps
• [ ] Wear OS / watchOS companion app if applicable to the use case
• [ ] App indexing configured — in-app content discoverable via Google Search / Spotlight Search

Payment & Financial System Production Checklist

---

🔴 CRITICAL (ship-blockers)

PCI DSS Compliance

• [ ] PCI DSS scope determined — identify all systems that store, process, or transmit cardholder data (minimize scope by using tokenization)
• [ ] Cardholder data NEVER touches your servers — use PCI-compliant hosted payment fields (Stripe Elements, Braintree Drop-in, Adyen Components)
• [ ] If handling card data directly: PCI DSS Level 1 assessment completed by a Qualified Security Assessor (QSA)
• [ ] PCI DSS v4.0 requirement 6.4.3 satisfied: complete inventory of all scripts on payment pages with documented authorization for each
• [ ] PCI DSS v4.0 requirement 11.6.1 satisfied: real-time detection and alerting on unauthorized changes to payment page elements (HTML, scripts, iframes)
• [ ] SAQ (Self-Assessment Questionnaire) completed and filed with your acquiring bank — type depends on integration method (SAQ-A for hosted, SAQ-A-EP for iframes)
• [ ] Cardholder data not stored after authorization — no full PAN, CVV, or magnetic stripe data retained in any system (database, logs, files, backups)
• [ ] All cardholder data transmission encrypted with TLS 1.2+ — no fallback to older protocols
• [ ] Tokenization implemented: store payment method tokens from your payment processor, never raw card numbers
• [ ] Payment page served exclusively over HTTPS — no mixed content, no HTTP fallback
• [ ] Quarterly vulnerability scans by an Approved Scanning Vendor (ASV) passing with zero critical/high findings
• [ ] Annual penetration test completed on payment infrastructure (internal and external network segments)

Transaction Integrity

• [ ] Idempotency keys required on ALL payment mutation endpoints — duplicate requests must not cause duplicate charges
• [ ] Double-entry bookkeeping implemented: every financial operation creates balanced debit and credit entries (sum of all debits = sum of all credits)
• [ ] Ledger is append-only — corrections are recorded as new reversal entries, never as mutations of existing records
• [ ] All financial operations wrapped in database transactions with serializable or repeatable-read isolation level
• [ ] Amount and currency always stored and transmitted together — a bare numeric value without currency context is never valid
• [ ] Monetary amounts stored as integers in smallest unit (cents, paise) — never floating-point (no float/double for money)
• [ ] Transaction state machine is well-defined with explicit states: pending → processing → succeeded/failed — no ambiguous intermediate states
• [ ] Every transaction has a unique, immutable transaction ID generated server-side (UUID v7 or similar)
• [ ] Optimistic locking or row-level locking prevents race conditions on balance updates (no lost updates from concurrent requests)
• [ ] Partial failures handled: if payment succeeds but order creation fails, compensation logic triggers refund or retries order creation

Fraud Prevention

• [ ] Velocity checks implemented: limit transactions per card, per IP, per user within time windows (e.g., max 5 transactions per card per hour)
• [ ] Address Verification System (AVS) enabled for card-not-present transactions — flag mismatches
• [ ] CVV/CVC verification required for all card-not-present transactions
• [ ] 3D Secure (3DS2) / Strong Customer Authentication (SCA) implemented for EU payments per PSD2 regulation
• [ ] Device fingerprinting collected for risk scoring — flag transactions from suspicious devices, VPNs, or known fraud proxies
• [ ] Real-time fraud scoring integrated: either payment processor's built-in (Stripe Radar, Adyen Risk Engine) or third-party (Sift, Kount)
• [ ] High-risk transaction review queue established — suspicious transactions held for manual review before capture
• [ ] Card testing / carding attack detection: rate limit authorization attempts, flag rapid low-value charges from same IP
• [ ] Chargeback monitoring dashboard in place — track chargeback rate and get alerts before exceeding network threshold (1% Visa, 1% Mastercard)

Authorization & Access Control

• [ ] Payment endpoints require authenticated users — no anonymous payment initiation
• [ ] Admin payment operations (refunds, adjustments, manual charges) require elevated privileges with audit trail
• [ ] Separation of duties enforced: the person who initiates a refund cannot approve it (dual authorization for amounts above threshold)
• [ ] Payment API keys stored in secrets manager — never in code, config files, or environment files committed to Git
• [ ] Test/sandbox and production payment environments strictly separated — test keys never used in production, production keys never in dev
• [ ] Webhook signatures verified cryptographically — never trust unverified payment processor callbacks (Stripe: stripe-signature; PayPal: PAYPAL-TRANSMISSION-SIG)

---

🟡 IMPORTANT (should fix before launch)

Reconciliation & Accounting

• [ ] Automated reconciliation pipeline built: compare internal ledger against payment processor settlement reports daily
• [ ] Discrepancies flagged and routed to investigation queue — reconciliation failures never silently ignored
• [ ] Bank statement reconciliation automated where possible — match deposits to expected settlement amounts
• [ ] Reconciliation service runs as an independent system with its own data store — not a scheduled job attached to the main ledger
• [ ] End-of-day batch totals verified: sum of transactions processed matches sum reported by payment processor
• [ ] Failed payment retries tracked — know which payments are in retry and when they will be abandoned
• [ ] Settlement timing documented per payment method — credit card (T+2), ACH (T+3-5), wire (T+0-1) — cash flow projections accurate
• [ ] Financial reports generated: daily transaction summary, monthly revenue, refund rates, chargeback rates, fees paid to processors

Refunds & Disputes

• [ ] Full and partial refund flows implemented and tested end-to-end (API to ledger to payment processor to customer notification)
• [ ] Refund idempotency: duplicate refund requests for the same transaction are detected and rejected
• [ ] Refund limits enforced: cannot refund more than the original transaction amount, cannot refund an already-refunded transaction
• [ ] Refund processing time communicated to users — set expectations (3-5 business days for card refunds, 5-10 for ACH)
• [ ] Chargeback response workflow defined: evidence collection template, submission deadlines, escalation path
• [ ] Chargeback reason codes tracked and analyzed — identify patterns (fraud, product not received, subscription not canceled)
• [ ] Dispute evidence auto-collection: automatically gather receipt, shipping proof, usage logs, communication history for chargeback defense
• [ ] Credit memos / store credit as alternative refund method — reduce cash outflow while maintaining customer satisfaction

Multi-Currency & International Payments

• [ ] Currency stored as ISO 4217 code alongside amount in every record — { amount: 1999, currency: "USD" } never just 1999
• [ ] Currency conversion uses provider rates at transaction time — conversion rate recorded immutably with the transaction
• [ ] Rounding rules follow ISO 4217 currency exponent (USD: 2 decimal places, JPY: 0 decimal places, KWD: 3 decimal places)
• [ ] Display formatting uses Intl.NumberFormat or equivalent locale-aware formatter — never hardcode $ or comma separators
• [ ] FX markup/spread documented and disclosed to users where applicable (regulatory requirement in many jurisdictions)
• [ ] Multi-currency settlement configured with payment processor — settle in local currency to avoid double-conversion fees
• [ ] Currency mismatch prevention: verify that charge currency matches the currency displayed to the user at checkout
• [ ] Cross-border payment compliance: sanctions screening (OFAC, EU), restricted countries list maintained and enforced

Tax & Regulatory

• [ ] Tax calculation engine integrated (Stripe Tax, TaxJar, Avalara, Vertex) — tax computed at checkout based on customer location
• [ ] Tax amounts recorded as separate line items in ledger — never mixed with product revenue
• [ ] Tax ID / VAT number collection and validation for B2B transactions (EU VAT reverse charge, GST for India/Australia)
• [ ] Invoice generation automated: valid tax invoice with all required fields (seller info, buyer info, tax breakdown, invoice number)
• [ ] Digital services tax compliance for cross-border digital sales (EU MOSS/OSS, UK digital services, Australian GST)
• [ ] Receipt emitted for every successful transaction — sent via email and available in user dashboard
• [ ] KYC (Know Your Customer) verification integrated for payment amounts above regulatory thresholds
• [ ] AML (Anti-Money Laundering) screening: transactions screened against sanctions lists and suspicious activity reported per FinCEN/local regulations
• [ ] Money transmission license requirements reviewed — determine if your business model requires a license in operating jurisdictions

Subscriptions & Recurring Billing (if applicable)

• [ ] Subscription lifecycle fully implemented: creation, upgrade, downgrade, cancellation, pause, resume
• [ ] Proration logic correct for mid-cycle plan changes — tested for upgrade, downgrade, and cancellation scenarios
• [ ] Grace period configured for failed recurring payments — don't cancel immediately, retry with exponential backoff (dunning)
• [ ] Dunning email sequence configured: payment failed → retry scheduled → final warning → subscription suspended
• [ ] Involuntary churn tracked: failed payment rate, card update rate, recovery rate after dunning
• [ ] Card expiry detection: proactively notify users before their card expires (use Stripe Account Updater or similar for auto-update)
• [ ] Free trial abuse prevention: limit one trial per payment method or per device fingerprint
• [ ] Cancellation flow includes retention offers where appropriate — downgrade option, pause, or discount before confirming cancel
• [ ] Subscription status webhook handling is idempotent — handle out-of-order and duplicate webhook deliveries
• [ ] Revenue recognition aligned with ASC 606 / IFRS 15 — deferred revenue tracked for prepaid subscriptions

Audit Trail & Compliance

• [ ] Every financial state change logged with: timestamp (UTC), actor (user/system), action, before-state, after-state, IP address
• [ ] Audit logs are append-only and stored in tamper-evident storage (separate from application database, WORM storage or signed logs)
• [ ] Audit log retention meets regulatory requirements: 7 years for IRS/SOX, 5 years for PCI DSS, jurisdiction-specific for GDPR
• [ ] Admin actions on payment data produce audit entries: who accessed what, when, from where
• [ ] SOX compliance: financial controls documented, access to financial systems reviewed quarterly, segregation of duties enforced (if publicly traded)
• [ ] PCI DSS audit trail requirements: all access to cardholder data logged, log integrity monitoring in place, logs reviewed daily
• [ ] Audit trail exportable for regulatory examination — structured format (CSV, JSON) with complete chain of custody

Monitoring & Alerting

• [ ] Payment success rate monitored in real-time — alert if decline rate exceeds baseline by > 5% (indicates processor issue or fraud attack)
• [ ] Payment latency tracked: p50, p95, p99 for authorization, capture, and refund operations
• [ ] Payment processor health monitored — alert on elevated error rates or timeouts from processor API
• [ ] Chargeback rate monitored — alert at 0.5% (well before the 1% network threshold that triggers penalties)
• [ ] Revenue dashboards: GMV, net revenue, refund rate, average order value, payment method breakdown (updated real-time or hourly)
• [ ] Failed webhook delivery monitoring — ensure no payment events are lost (dead letter queue for failed webhook processing)
• [ ] Reconciliation discrepancy alerts — any mismatch between internal ledger and processor reports triggers investigation

---

🟢 NICE-TO-HAVE (polish)

• [ ] Multiple payment methods supported: cards, ACH/bank transfer, digital wallets (Apple Pay, Google Pay), Buy Now Pay Later (Klarna, Afterpay)
• [ ] Saved payment methods: users can save and manage multiple cards/bank accounts (using processor tokenization, never storing raw data)
• [ ] One-click checkout for returning customers (Stripe Link, Shop Pay, PayPal One Touch)
• [ ] Payment method fallback: if primary payment method fails, automatically try backup method (requires user opt-in)
• [ ] Split payments / marketplace payouts implemented: funds distributed to multiple recipients per transaction (Stripe Connect, PayPal for Marketplaces)
• [ ] Payout scheduling: sellers/creators paid on configurable schedule (daily, weekly, monthly) with minimum threshold
• [ ] Payment analytics: conversion funnel tracking from cart to payment success, drop-off analysis by payment method and device
• [ ] Smart payment routing: route transactions to the processor with highest approval rate for the card type/region
• [ ] Network tokenization enabled: store network tokens for improved approval rates and automatic card updates (Visa Token Service, Mastercard MDES)
• [ ] 3DS challenge optimization: use risk-based authentication to minimize friction for low-risk transactions (exemption engine)
• [ ] Automated accounting integration: sync transactions to QuickBooks, Xero, or NetSuite in real-time
• [ ] Multi-processor failover: if primary payment processor is down, route to backup processor within seconds
• [ ] Crypto payment option available if relevant to user base (USDC, ETH via provider like Coinbase Commerce, BitPay)
• [ ] Pre-authorization and delayed capture for order-type workflows (authorize at order, capture at shipment)
• [ ] Subscription pause/resume: users can temporarily pause subscriptions without canceling (retention tool)
• [ ] Usage-based billing: track metered usage and generate invoices based on consumption (for SaaS/API products)
• [ ] Dynamic currency conversion: show prices in customer's local currency with real-time conversion rates
• [ ] Payment receipt customization: branded receipts with itemized breakdown, tax details, and support contact

Smart Contract Production Checklist (Solidity / EVM)

---

🔴 CRITICAL (ship-blockers)

Audit & Security Review

• [ ] Third-party security audit completed by a reputable firm (Trail of Bits, OpenZeppelin, Cyfrin, Sherlock, Spearbit, Consensys Diligence)
• [ ] All Critical and High severity audit findings resolved and re-verified before mainnet deployment
• [ ] Slither static analysis run — all findings reviewed, false positives documented, real issues fixed
• [ ] Mythril or MythX deep analysis run — no unresolved critical findings
• [ ] Reentrancy protection verified: follow Checks-Effects-Interactions pattern AND use ReentrancyGuard on all external call paths
• [ ] No unchecked arithmetic in critical calculations (Solidity < 0.8.x: use SafeMath everywhere; ≥ 0.8.x: verify unchecked blocks are safe)
• [ ] Access control verified on ALL privileged functions — no unprotected onlyOwner/admin functions (use OpenZeppelin Ownable2Step or AccessControl)
• [ ] No hardcoded private keys, deployer addresses, or secrets anywhere in contract code or deployment scripts
• [ ] No selfdestruct / delegatecall to untrusted addresses — both are common exploit vectors
• [ ] All external calls to untrusted contracts are treated as potentially malicious (no assumptions about return values)
• [ ] tx.origin never used for authorization — only msg.sender (tx.origin enables phishing attacks)
• [ ] Integer overflow/underflow edge cases tested at type(uint256).max and 0 boundaries for all arithmetic
• [ ] Storage collision verified for all proxy patterns — use EIP-1967 storage slots, verified with forge inspect or OZ Upgrades plugin
• [ ] No uninitialized proxy contracts — implementation contracts have _disableInitializers() in constructor
• [ ] Signature replay attacks prevented — signatures include chain ID, contract address, nonce, and deadline
• [ ] Front-running protection on sensitive operations — commit-reveal, private mempool (Flashbots Protect), or batch auctions where needed

Testing

• [ ] Unit tests cover ALL public and external functions — minimum 95% line coverage, 90% branch coverage
• [ ] Integration tests cover all cross-contract interactions, including interactions with external protocols
• [ ] Fuzz testing run with meaningful corpus: Foundry forge fuzz (≥ 10,000 runs) or Echidna with custom property tests
• [ ] Edge cases explicitly tested: zero value transfers, zero address, max uint256, empty arrays, reentrancy attempts
• [ ] Fork tests run against live mainnet state to verify integration with deployed contracts (Hardhat fork / Foundry --fork-url)
• [ ] Invariant tests defined and passing: total supply consistency, balance sum = total supply, no unauthorized minting
• [ ] Gas limits tested: no function exceeds block gas limit under worst-case input
• [ ] Upgrade path tested end-to-end: deploy v1, upgrade to v2, verify state preservation and new functionality
• [ ] Failure mode tests: what happens when external calls revert, when oracle returns stale data, when user sends ETH to non-payable function
• [ ] Time-dependent logic tested with vm.warp — verify behavior at boundary timestamps (vesting cliffs, unlock periods, deadline expiry)

Deployment Configuration

• [ ] Contract deployed and fully tested on public testnet first (Sepolia, Base Sepolia, Arbitrum Sepolia) — identical bytecode
• [ ] Exact same bytecode deployed to mainnet as what was audited — verify with diff on compilation artifacts
• [ ] Constructor arguments and initialization parameters double-checked — these are permanent and immutable once deployed
• [ ] Multi-sig wallet (Safe, formerly Gnosis Safe) controls all admin/owner functions — never a single EOA in production
• [ ] Emergency pause mechanism implemented via OpenZeppelin Pausable on critical contracts (mint, transfer, withdraw)
• [ ] Upgrade proxy pattern (if used) reviewed for storage collision: verify storage layout compatibility with forge inspect or Hardhat storage layout plugin
• [ ] Deployment scripts are deterministic and reproducible — use CREATE2 for predictable addresses if cross-chain deployment needed
• [ ] Deployer wallet has sufficient gas but is NOT the permanent admin — transfer ownership to multi-sig immediately after deploy
• [ ] Deployment transaction simulated on Tenderly or fork before submitting to mainnet — verify all state changes are expected
• [ ] Emergency contacts and war room established before mainnet deploy — team available for 24-48 hours post-launch

---

🟡 IMPORTANT (should fix before launch)

Code Quality & Standards

• [ ] Compiler version pinned to exact latest stable release: pragma solidity 0.8.x; (replace x with latest patch) — never ^0.8.0 or floating ranges in production
• [ ] Latest stable Solidity compiler used (check solidity releases for security patches)
• [ ] OpenZeppelin Contracts library used for standard implementations: ERC-20, ERC-721, ERC-1155, AccessControl, Pausable
• [ ] No unused variables, imports, dead code, or unreachable branches — clean compilation output
• [ ] NatSpec documentation (@notice, @param, @return, @dev) on all public and external functions
• [ ] Code compiles with zero warnings — treat warnings as errors in CI (--warnings-as-errors in Foundry)
• [ ] Functions use most restrictive visibility: external over public when not called internally (gas savings + clarity)
• [ ] assembly / inline Yul blocks minimized and each accompanied by a safety comment explaining why it's necessary
• [ ] Custom errors used instead of require strings for gas efficiency (error InsufficientBalance() instead of require(balance >= amount, "insufficient"))
• [ ] All magic numbers extracted to named constants (e.g., uint256 constant MAX_SUPPLY = 10_000;)
• [ ] EIP compliance verified for all token standards — pass reference test suites (ERC-20: transfer, approve, transferFrom; ERC-721: safeTransferFrom, tokenURI)
• [ ] Natspec @inheritdoc used for interface implementations — documentation stays in sync with interface

Gas Optimization

• [ ] Gas profiling done: forge test --gas-report or Hardhat gas reporter — no unexpected high-cost functions
• [ ] Storage variables packed into 32-byte slots where possible (e.g., group uint128 + uint128 together, address + uint96)
• [ ] uint256 used by default — smaller uints (uint8, uint128) only when deliberately packing storage slots
• [ ] Loops have bounded iteration with explicit max — no unbounded loops over dynamic storage arrays (DoS vector)
• [ ] Events emitted for all significant state changes to enable off-chain indexing without polling
• [ ] calldata used instead of memory for external function parameters that aren't modified
• [ ] Mappings preferred over arrays for lookups — O(1) vs O(n) gas cost
• [ ] Batch operations provided where users may need to call the same function multiple times (batch mint, batch transfer)
• [ ] Cold vs warm storage access patterns optimized — cache storage reads in memory variables when accessed multiple times in a function
• [ ] EIP-2930 access lists considered for contracts with known cross-contract storage access patterns

Operational Security

• [ ] Admin key management plan documented and implemented: hardware wallet (Ledger/Trezor), MPC wallet, or multi-sig — never a hot wallet
• [ ] Timelock contract deployed for privileged operations — minimum 24-48h delay so community can react to malicious governance (OpenZeppelin TimelockController)
• [ ] Oracle price feeds use TWAP or Chainlink price feeds with staleness checks — never spot price from a single DEX (manipulation risk)
• [ ] Flash loan attack vectors assessed: no single-transaction price manipulation possible on key operations
• [ ] MEV protection considered for user-facing transactions: Flashbots Protect RPC or MEV-resistant design patterns
• [ ] Protocol TVL limit / deposit cap set for initial launch — start small and increase as confidence builds
• [ ] Emergency contacts documented: who can trigger pause, how to reach multi-sig signers, escalation for exploits
• [ ] Multi-sig threshold appropriate: at least 3-of-5 for protocol admin, never 1-of-N for critical operations
• [ ] Key rotation plan documented — what happens if a signer's key is compromised? (Remove signer, add new one, rotate multi-sig)
• [ ] Monitoring alerts configured for admin function calls — any onlyOwner execution triggers real-time notification to team
• [ ] Timelock transactions monitored publicly — community tools or bots notify stakeholders of pending governance actions

Documentation & Communication

• [ ] Technical documentation published: architecture diagram, state machine, contract interaction flow, trust assumptions
• [ ] All external dependencies documented with addresses and versions: oracles, other protocols, bridges, token contracts
• [ ] Known limitations, risks, and trust assumptions disclosed publicly (user-facing risk documentation)
• [ ] Bug bounty program live BEFORE mainnet launch — rewards commensurate with TVL (Immunefi, HackerOne, Code4rena)
• [ ] Deployment addresses published in a verified registry (GitHub README, docs site, Etherscan verification)
• [ ] Upgrade/governance process documented publicly so users understand who can change what
• [ ] Incident response playbook published: what the team will do in case of exploit, who communicates, how funds are recovered
• [ ] User-facing documentation: how to interact with the protocol, what risks exist, how to verify contract addresses

DeFi-Specific (if applicable)

• [ ] Liquidity pool manipulation tested — verify protocol is safe under extreme price movements (10x, 100x) and near-zero liquidity
• [ ] Sandwich attack resistance verified — user-facing swaps have slippage protection and deadline parameters
• [ ] Liquidation mechanism tested under extreme market conditions — verify no bad debt accumulates
• [ ] Interest rate model behavior verified at boundary conditions — 0% utilization, 100% utilization, rate jumps
• [ ] Token approval patterns safe — use permit (EIP-2612) or increaseAllowance instead of raw approve to prevent front-running
• [ ] Yield calculations verified for precision — no rounding errors that compound over time (use fixed-point math libraries)
• [ ] Vault share price manipulation prevented — first depositor attack mitigated with virtual shares or minimum deposit
• [ ] Reward distribution arithmetic verified — accumulated rewards don't overflow, division-before-multiplication errors eliminated
• [ ] Withdrawal queue or cooldown tested — users can always exit, even during high-demand periods (no permanent lock)

Cross-Chain (if applicable)

• [ ] Bridge message validation: source chain, sender address, and payload integrity verified on destination chain
• [ ] Replay protection across chains — message nonces or unique identifiers prevent the same message from being processed twice
• [ ] Chain-specific gas differences accounted for — L2 gas costs, sequencer uptime, and finality times mapped per target chain
• [ ] Canonical deployment addresses consistent across chains (CREATE2 with same salt) or clearly documented per-chain
• [ ] Cross-chain message failure handling: what happens if a message fails on the destination chain? (Retry mechanism, refund path)

---

🟢 NICE-TO-HAVE (polish)

• [ ] Formal verification run for invariant-critical logic (Certora Prover, Halmos, KEVM) — especially for DeFi core accounting
• [ ] Source code verified on Etherscan/Basescan AND Sourcify immediately after deployment
• [ ] Subgraph deployed for efficient off-chain indexing and querying (The Graph — hosted or decentralized)
• [ ] Real-time monitoring configured for anomalous on-chain activity: large transfers, admin function calls, unusual patterns (OpenZeppelin Defender, Forta, Tenderly)
• [ ] Token distribution / vesting contracts audited separately from core protocol (different risk profile)
• [ ] DAO governance contracts reviewed for vote manipulation: flash loan governance attacks, vote buying, low-quorum exploits
• [ ] Cross-chain bridge contracts receive independent bridge-specific security review (bridges are highest-risk category)
• [ ] Disaster recovery plan documented: what happens if admin key is compromised, if oracle fails, if critical bug is found post-launch
• [ ] War room / incident response drill conducted: simulate a security incident and practice the response process
• [ ] Gas sponsorship / meta-transactions implemented for better UX (ERC-2771, Account Abstraction ERC-4337)
• [ ] Contract supports ERC-165 supportsInterface for composability with other protocols
• [ ] Multi-chain deployment plan documented with chain-specific considerations (L1 vs L2 gas, sequencer downtime, bridge finality)
• [ ] On-chain event indexing strategy documented — which events are indexed, by which services, with what latency
• [ ] Protocol simulation run with agent-based modeling — test economic incentives under adversarial conditions
• [ ] Insurance coverage evaluated — protocol-level insurance via Nexus Mutual, InsurAce, or similar
• [ ] Token economic audit completed — verify tokenomics (supply, emission, burning) match whitepaper and documentation
• [ ] Governance proposal simulation tested — end-to-end from proposal creation to execution through timelock

Web / Frontend Production Checklist

---

🔴 CRITICAL (ship-blockers)

Security

• [ ] All environment variables are in .env and NOT committed to Git (check .gitignore includes .env*)
• [ ] HTTPS is enforced on all routes — no mixed content warnings (set up automatic HTTP → HTTPS redirect)
• [ ] Content Security Policy (CSP) headers configured (start with Content-Security-Policy: default-src 'self' and expand per resource)
• [ ] Security headers set: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security: max-age=31536000; includeSubDomains
• [ ] No hardcoded API keys, secrets, or tokens in client-side code (search codebase for sk_, api_key, secret, password)
• [ ] Authentication tokens stored in httpOnly secure cookies — NOT localStorage or sessionStorage (XSS can steal localStorage; if cookies are not feasible for your SPA architecture, use short-lived tokens with refresh token rotation)
• [ ] CORS restricted to known origins — never Access-Control-Allow-Origin: * in production (set explicit domain allowlist)
• [ ] Rate limiting enabled on all public-facing form submissions and API routes (use middleware like express-rate-limit or Cloudflare rules)
• [ ] SSL/TLS certificate is valid and auto-renews (check expiry date; use Let's Encrypt or your host's managed certs)
• [ ] No sensitive data exposed in URL query parameters (tokens, emails, passwords must go in request body or headers)
• [ ] Subresource Integrity (SRI) hashes set on third-party <script> and <link> tags if loading from CDNs (add integrity attribute)
• [ ] Referrer-Policy header set to strict-origin-when-cross-origin or stricter
• [ ] Permissions-Policy header configured to disable unused browser features (camera, microphone, geolocation, payment — deny what you don't need)
• [ ] All user-generated content sanitized before rendering — use DOMPurify or framework-native sanitization to prevent stored XSS
• [ ] No eval(), innerHTML, or document.write() with user-controlled data (use textContent or framework bindings)
• [ ] CSP script-src does NOT include 'unsafe-inline' or 'unsafe-eval' in production (use nonces or hashes instead)
• [ ] All third-party scripts on payment pages inventoried and authorized — PCI DSS 4.0 requirement 6.4.3 (maintain a script inventory with integrity checks)
• [ ] Payment page changes detected in real-time — PCI DSS 4.0 requirement 11.6.1 (use CSP reporting or a client-side security tool like Feroot/c/side)
• [ ] Session fixation prevented — regenerate session ID on login and privilege escalation
• [ ] Clickjacking protection verified — X-Frame-Options: DENY and CSP frame-ancestors 'none' both set

Functionality

• [ ] All critical user flows tested end-to-end on the actual production build (signup, login, checkout, payment, password reset)
• [ ] Custom 404 page exists, is on-brand, and includes navigation back to the app
• [ ] Custom 500 / error page exists — users never see a raw stack trace or framework error page
• [ ] No console.log, console.error, or debugger statements leaking sensitive data in production build (use build-time stripping)
• [ ] All external API calls have error handling, loading states, and user-friendly fallback UI
• [ ] Forms have both client-side and server-side validation (never trust client-only validation)
• [ ] Empty states, zero-data states, and loading skeletons implemented for all dynamic content
• [ ] User-facing error messages are helpful and non-technical (no "undefined is not a function")
• [ ] Logout functionality works correctly — clears all session data, tokens, and cached sensitive content
• [ ] Session timeout implemented for idle users — redirect to login with a clear message after inactivity threshold
• [ ] File upload inputs validate file type, size, and content on both client and server (never trust client-only checks)
• [ ] All redirects validated — no open redirect vulnerabilities (whitelist allowed redirect destinations)

Deployment

• [ ] CI/CD pipeline runs and passes all tests on the production branch before deploy
• [ ] Rollback procedure is documented and has been tested at least once (know how to revert within 5 minutes)
• [ ] Production environment variables are set and differ from staging/dev (especially API URLs, database strings, feature flags)
• [ ] DNS is configured and propagated — domain points to the correct production server/CDN (verify with dig or DNS checker)
• [ ] Source maps are uploaded to error tracking service but NOT served publicly (prevents reverse-engineering)
• [ ] Build artifacts are immutable and versioned — same build artifact deploys to staging and production (no "build in prod")
• [ ] Zero-downtime deployment configured — users never see a maintenance page during routine deploys (blue-green, rolling, or atomic deploys)
• [ ] Health check endpoint exists and is monitored — load balancer only routes to healthy instances

---

🟡 IMPORTANT (should fix before launch)

Performance

• [ ] Lighthouse score ≥ 90 on Performance, Accessibility, and Best Practices (run on production URL, not localhost)
• [ ] Core Web Vitals pass: LCP < 2.5s, INP < 200ms, CLS < 0.1 (test with PageSpeed Insights on real URL)
• [ ] Images use next-gen formats (WebP or AVIF) with fallbacks and are lazy-loaded (loading="lazy")
• [ ] Images are properly sized — no serving 4000px images in 400px containers (use srcset and sizes)
• [ ] JS and CSS are minified, tree-shaken, and code-split (verify no unused code ships to the client)
• [ ] Static assets served via CDN with cache headers (Cache-Control: public, max-age=31536000, immutable for hashed assets)
• [ ] Fonts are subset to used characters and loaded with font-display: swap (or optional to avoid layout shift)
• [ ] No render-blocking resources in <head> — defer non-critical JS, inline critical CSS
• [ ] Bundle size analyzed and within budget — no single route JS chunk > 200KB gzipped (use source-map-explorer or @next/bundle-analyzer)
• [ ] Server-side or edge caching configured for repeated data queries (Redis, Vercel KV, Cloudflare KV, or framework cache)
• [ ] Third-party scripts audited for size and load impact — defer or lazy-load analytics, chat widgets, etc.
• [ ] <link rel="preload"> used for critical above-the-fold assets (hero image, primary font)
• [ ] Long tasks broken up — no single JS task blocks the main thread for > 50ms (use requestIdleCallback, Web Workers, or chunking)
• [ ] Service Worker or edge caching provides stale-while-revalidate for non-critical data
• [ ] Database queries behind the frontend are paginated — no endpoints return unbounded result sets
• [ ] Memory leaks checked — no growing heap from event listeners, intervals, or subscriptions left open on unmount

SEO & Metadata

• [ ] Unique <title> and <meta name="description"> on every page (title 30–60 chars, description 120–155 chars)
• [ ] Open Graph tags set: og:title, og:description, og:image (1200×630px), og:url, og:type
• [ ] Twitter Card tags set: twitter:card, twitter:title, twitter:description, twitter:image
• [ ] sitemap.xml generated and submitted to Google Search Console (auto-generate on build for dynamic sites)
• [ ] robots.txt configured — not accidentally blocking production (check Disallow rules)
• [ ] Canonical URLs set with <link rel="canonical"> on every page to prevent duplicate content indexing
• [ ] Structured data (JSON-LD) on key pages — at minimum: Organization, WebSite, BreadcrumbList (validate with Google Rich Results Test)
• [ ] All pages are server-rendered or pre-rendered for SEO-critical content (SPAs need SSR/SSG for crawlability)
• [ ] <html lang="..."> attribute set correctly for primary language
• [ ] Paginated content uses canonical URLs pointing to the preferred page (note: Google no longer uses rel="next"/rel="prev" as ranking signals)
• [ ] 301 redirects configured for all old URLs if migrating from a previous site (preserve SEO equity)

Accessibility

• [ ] All images have meaningful alt text (decorative images use alt="")
• [ ] Color contrast meets WCAG 2.2 AA: 4.5:1 for normal text, 3:1 for large text (check with browser DevTools or Stark)
• [ ] All interactive elements are keyboard-navigable — test full flows using only Tab, Enter, Escape, Arrow keys
• [ ] Focus indicators are visible on all interactive elements (never set outline: none without a replacement)
• [ ] ARIA labels on icon-only buttons, form inputs, and non-semantic interactive elements
• [ ] Heading hierarchy is logical — one <h1> per page, no skipped levels (<h1> → <h3> without <h2>)
• [ ] Form fields have associated <label> elements (not just placeholder text)
• [ ] Tested with at least one screen reader (VoiceOver on Mac, NVDA on Windows) on critical flows
• [ ] Skip navigation link provided for keyboard users (Skip to main content)
• [ ] Animations respect prefers-reduced-motion media query
• [ ] Touch targets ≥ 44×44px on mobile — WCAG 2.2 Target Size criterion (2.5.8)
• [ ] Error messages programmatically associated with form fields using aria-describedby or aria-errormessage
• [ ] Dynamic content updates announced to screen readers via aria-live regions (toasts, notifications, form errors)
• [ ] Drag-and-drop interactions have keyboard-accessible alternatives
• [ ] Color is not the only visual indicator for status, errors, or required fields (add icons, text, or patterns)

Internationalization (i18n) & Localization

• [ ] All user-facing strings externalized into resource files — no hardcoded text in components (use react-intl, next-intl, i18next, etc.)
• [ ] Date, time, number, and currency formatting uses Intl API or locale-aware library (never hardcode MM/DD/YYYY)
• [ ] Right-to-left (RTL) layout support implemented if serving Arabic, Hebrew, or other RTL locales (use CSS direction: rtl and logical properties)
• [ ] Text expansion accounted for — German and French can be 30-40% longer than English (no fixed-width containers that clip translated text)
• [ ] Locale detected from user preference (Accept-Language header, browser setting, or user profile) — not from IP geolocation alone
• [ ] Unicode properly supported — emojis, CJK characters, and diacritics render correctly in all text fields and databases

Monitoring & Observability

• [ ] Client-side error tracking configured and verified — errors flow to dashboard (Sentry, Datadog RUM, LogRocket)
• [ ] Analytics installed and tracking key events: page views, signups, conversions (GA4, PostHog, Plausible, Mixpanel)
• [ ] Uptime monitoring set up — alerts on downtime (Better Uptime, Freshping, UptimeRobot, Checkly)
• [ ] Real User Monitoring (RUM) enabled to track actual user Core Web Vitals (Vercel Analytics, Datadog RUM, SpeedCurve)
• [ ] Alerts configured for error rate spikes (e.g., > 5% error rate triggers PagerDuty/Slack notification)
• [ ] CSP violation reporting enabled — report-uri or report-to directive sends violations to a monitoring endpoint
• [ ] Client-side performance budgets enforced in CI — fail the build if bundle size or LCP regresses beyond threshold
• [ ] User session replay available for debugging production issues (LogRocket, FullStory, PostHog — ensure PII is masked)

Cross-Browser & Device Testing

• [ ] Tested on latest Chrome, Firefox, Safari, and Edge (cover > 95% of users)
• [ ] Tested on mobile browsers: iOS Safari and Android Chrome at minimum
• [ ] Responsive design verified at common breakpoints: 375px, 768px, 1024px, 1440px
• [ ] Touch interactions work correctly on mobile (tap targets ≥ 44×44px, no hover-only interactions)
• [ ] Tested with browser zoom at 200% — content remains usable and readable (WCAG 1.4.4)
• [ ] Tested with browser text scaling at 200% — no text clipping or overflow (WCAG 1.4.4)

Legal & Compliance

• [ ] Privacy policy page exists and is accessible from every page (footer link)
• [ ] Cookie consent banner implemented if serving EU/UK users (GDPR) or other regulated regions — blocks non-essential cookies until consent
• [ ] Terms of service page exists if users create accounts or transact
• [ ] Data processing agreements in place with third-party services that handle user data
• [ ] CCPA "Do Not Sell or Share My Personal Information" link visible if serving California users
• [ ] Data subject access request (DSAR) flow exists — users can request export or deletion of their personal data
• [ ] Age verification or COPPA compliance implemented if app could attract users under 13
• [ ] Accessibility statement published if required by jurisdiction (ADA, EAA European Accessibility Act 2025)
• [ ] Cookie policy details all cookies, their purpose, duration, and third-party origins

Payment Frontend (if applicable)

• [ ] Payment forms use PCI-compliant hosted fields or iframes (Stripe Elements, Braintree Drop-in, Adyen Web Components) — never collect raw card numbers in your own forms
• [ ] Payment page served over HTTPS with valid TLS 1.2+ — no mixed content allowed on checkout pages
• [ ] Payment page script integrity verified — ensure no unauthorized scripts load on checkout (complement the CRITICAL-tier PCI DSS 6.4.3 requirement with automated monitoring)
• [ ] Payment confirmation page shows transaction ID, amount, and clear success/failure status
• [ ] Double-submit prevention on payment buttons — disable button after click, use idempotency keys
• [ ] Failed payment UX is clear — show specific error messages (card declined, insufficient funds, expired card) not generic errors
• [ ] Saved payment methods display masked card numbers only (last 4 digits) — never show full card number
• [ ] Payment form autofill works correctly with browser autocomplete attributes (cc-name, cc-number, cc-exp, cc-csc)
• [ ] 3D Secure / Strong Customer Authentication (SCA) flow implemented for EU payments per PSD2 regulation

---

🟢 NICE-TO-HAVE (polish)

• [ ] Favicon set: favicon.ico + apple-touch-icon.png (180×180) + web manifest icons (use realfavicongenerator.net)
• [ ] PWA manifest configured with name, short_name, icons, theme_color, start_url
• [ ] Service worker for offline support or asset caching (if PWA)
• [ ] Print stylesheet provided for content-heavy pages (@media print)
• [ ] Broken links checked and fixed (use W3C link checker, Screaming Frog, or linkinator)
• [ ] rel="preconnect" for critical third-party origins (fonts.googleapis.com, CDN, analytics)
• [ ] HTTP/2 or HTTP/3 enabled on the server (most CDNs/hosts do this by default — verify)
• [ ] HSTS preload submitted at hstspreload.org (after confirming HSTS header works)
• [ ] Dependency audit run — no known vulnerabilities (npm audit, pnpm audit, or Snyk)
• [ ] Adblocker compatibility tested — critical features not broken by common adblockers
• [ ] 404 page includes search or suggested links to reduce bounce rate
• [ ] Proper Cache-Control for HTML pages (no-cache or short TTL to ensure fresh deploys are picked up)
• [ ] Social share preview tested with actual URLs (use opengraph.xyz or metatags.io)
• [ ] RSS feed available for blog/content sites
• [ ] Web app handles deep links / direct URL access correctly (no blank pages on refresh for SPAs)
• [ ] Client-side feature flags integrated for safe UI rollouts and instant kill switches (LaunchDarkly, Flagsmith, Unleash, or config-based)
• [ ] A/B testing infrastructure in place for conversion-critical pages (Optimizely, PostHog, GrowthBook)
• [ ] prefers-color-scheme media query supported for dark mode (or manual toggle provided)
• [ ] prefers-contrast media query respected for high-contrast mode users
• [ ] Stale content detection — cache-busting strategy ensures users never see outdated JS/CSS after deploy
• [ ] DNS prefetch (<link rel="dns-prefetch">) for all third-party domains referenced on the page
• [ ] Web Vitals tracking in CI — automated Lighthouse or Web Vitals regression testing on every PR
• [ ] Content Delivery Network configured with geographic distribution matching user base (multi-region PoPs)
• [ ] Edge functions / middleware used for geo-routing, A/B testing, or bot detection at the CDN layer