Every Pre-Launch Checklist Audit check

Misconfigured DNS is one of the top launch-day failure modes for vibe-coded projects. A custom domain referenced in code but not pointed at the hosting provider produces broken canonical URLs, OAuth callback mismatches (login stops working), and email links that resolve to nothing. Under ISO 25010:2011 reliability.availability, this is a hard availability failure: the app is deployed but unreachable at its intended address. Because DNS propagation takes up to 48 hours, discovering this on launch day means a day of downtime.

Why this severity: High because an unconfigured custom domain makes the production app unreachable and breaks every integration that depends on the canonical URL, from OAuth redirects to email links.

An expired or self-signed SSL certificate triggers browser security warnings that block every user from accessing the site, destroying conversions and search engine trust simultaneously. CWE-295 and OWASP A02 both flag unvalidated certificates as a critical attack surface: a lapsed cert is trivially exploitable by any network-path attacker via downgrade or MITM. Most vibe-coded projects rely on hosting platforms for automatic provisioning, but custom server deployments or certbot misconfigurations can silently fail to renew, leaving the site offline on a Sunday at 3am.

Why this severity: Critical because a lapsed certificate takes the entire site offline for all users and opens every in-flight session to network interception under CWE-295.

Serving identical content at both www.yourdomain.com and yourdomain.com splits link equity between two URLs, creating duplicate content that Google may rank separately or penalize. Social shares, backlinks, and analytics fragment across hostnames, distorting traffic attribution. Users bookmarking the wrong variant land on an inconsistent canonical, and session cookies scoped to one host break authentication on the other.

Why this severity: Medium because SEO and analytics damage compounds silently over time but does not break functionality or expose data.

Shipping a production app with test or sandbox credentials is among the most common vibe-coded project failures: Stripe charges go nowhere (`pk_test_` keys process no real money), transactional emails vanish into sandbox inboxes, and OAuth flows silently reject real user tokens. CWE-798 and OWASP A05 both flag hardcoded or misconfigured credentials as a critical vulnerability class. Beyond service failures, a localhost `DATABASE_URL` in production means every API call hits a dead connection — the app appears live but is entirely non-functional.

Why this severity: Critical because test credentials silently disable payment processing, email delivery, and third-party authentication in production — users take real actions that produce no real outcome.

Debug mode in production exposes stack traces, internal file paths, verbose application state, and detailed error messages directly to users and attackers. CWE-215 (Information Exposure Through Debug Information) and CWE-11 both describe this class of vulnerability: an attacker who can trigger an error in debug mode learns your framework version, database schema hints, and code structure — all inputs for targeted exploitation. OWASP A05 (Security Misconfiguration) lists debug-enabled production as a canonical misconfiguration. Beyond security, verbose logging inflates log costs and obscures real signals.

Why this severity: Critical because active debug flags expose stack traces and application internals to any user who can trigger an error, directly aiding targeted attacks per CWE-215.

A `gmail.com` or `yahoo.com` from-address on a custom-domain site triggers stricter spam filtering at Gmail, Outlook, and Yahoo — DMARC alignment fails because the envelope domain does not match the visible sender. Password resets and transactional mail land in spam or bounce. Users also read the mismatch as amateur-hour, eroding trust on exactly the touchpoints (billing receipts, support replies) where credibility matters most.

Why this severity: Info because deliverability and perception suffer but no security boundary or compliance rule is directly broken.

GDPR Article 13, CCPA §1798.100, and Brazil's LGPD Article 9 all require that users be informed about data collection before or at the time their data is collected. Any application that uses analytics, session cookies, contact forms, or authentication collects personal data — which triggers mandatory disclosure requirements. Operating without a privacy policy exposes the business to regulatory fines (GDPR penalties reach 4% of global turnover) and removes the legal basis for processing user data at all. Courts and regulators treat absence of a privacy policy as evidence of willful non-compliance.

Why this severity: Critical because launching without a privacy policy is a direct GDPR/CCPA compliance violation that exposes the business to regulatory fines and removes the legal basis for data processing.

Without a terms-of-service page, you have no written agreement limiting liability, defining acceptable use, or establishing governing law — disputes default to whatever jurisdiction the plaintiff chooses. Payment processors including Stripe require terms for high-risk categories, and app stores reject submissions that lack them. User-generated content sites face DMCA exposure without a takedown clause, and subscription products cannot enforce refund policies that users never agreed to.

Why this severity: High because it creates direct legal and financial exposure on any site with accounts, payments, or user content.

GDPR Article 7 and the ePrivacy Directive Article 5(3) require affirmative, informed consent before setting non-essential cookies or activating tracking scripts for EU users. Loading Google Analytics, Mixpanel, Hotjar, or any advertising pixel without prior consent is a direct ePrivacy violation — not a gray area. Supervisory authorities across the EU have issued fines in this category ranging from four figures for small sites to multi-million-euro penalties for larger operators. CCPA §1798.120 adds opt-out requirements for California users. Most vibe-coded projects wire analytics unconditionally in `app/layout.tsx` without ever implementing a consent gate.

Why this severity: High because unconditional analytics loading violates the ePrivacy Directive and GDPR Art. 7 for any EU visitor, with documented regulatory fines even for small operators.

The default framework 404 page exposes the framework name, version, and sometimes internal routing details — information an attacker uses to target known vulnerabilities (CWE-756). Beyond security, every user who hits a 404 without navigation options bounces permanently. A custom 404 page with a link back to the homepage recovers a portion of those users who arrived at a broken or moved URL, directly reducing churn from mislinked campaigns, renamed routes, and user typos.

Why this severity: Medium because the default 404 leaks framework internals per CWE-756 and abandons users with no navigation path, causing recoverable but significant UX and minor information-disclosure harm.

The default framework error page in production often renders stack traces, internal file paths, and framework version information directly in the browser — feeding an attacker a precise map of the application's internal structure (CWE-209). OWASP A05 lists this as a Security Misconfiguration. Equally important: an error page that shows a friendly message but discards the error object silently means production failures are invisible. You need both — a safe user-facing message and server-side error capture so you know the failure happened.

Why this severity: High because a default or stack-trace-rendering error page exposes application internals per CWE-209, while a completely silent error boundary leaves production failures undetected.

A missing favicon shows the browser's default blank-page icon in tabs, bookmarks, browser history, and pinned tabs — the site reads as unfinished next to every other tab the user has open. Chrome and Safari also render the blank icon in mobile tab switchers and Add-to-Home-Screen prompts. On shared devices and in screenshots, the missing brand mark makes your site indistinguishable from a localhost dev server.

Why this severity: Medium because the polish gap is universally visible to every visitor and undermines brand recall on every tab.

When an iOS user taps Share then Add to Home Screen, Safari looks for an apple-touch-icon. Without one, iOS generates a low-contrast screenshot of the current page and crops it into the icon slot — the home-screen launcher ends up with an unreadable thumbnail instead of your brand mark. This silently degrades the install experience on the platform where home-screen launches correlate most strongly with retention.

Why this severity: Low because the impact is limited to iOS home-screen users, a small slice of total traffic.

When a URL is shared on Twitter/X, LinkedIn, Slack, iMessage, or WhatsApp, those platforms fetch Open Graph and Twitter Card metadata to generate a rich link preview with title, description, and image. Without `og:image` — the single most important OG tag — links render as plain text with no visual. This directly suppresses click-through rates on your launch announcements, Product Hunt submission, and any social campaign. A missing OG image is a silent launch tax: every share underperforms without it.

Why this severity: Medium because absent OG metadata degrades every social share to plain text with no preview image, directly suppressing click-through rates on launch announcements without creating a security risk.

Over 60% of web traffic globally originates from mobile devices. A non-responsive layout — fixed-width containers with no breakpoints — renders unreadably small on phones, forcing users to pinch-zoom or abandon entirely. WCAG 2.2 SC 1.4.4 (Resize Text) and 1.3.4 (Orientation) mandate that content reflows at different viewport sizes. Beyond accessibility compliance, a broken mobile experience means most of your launch-day traffic lands on an unusable product, suppressing conversion and retention from day one.

Why this severity: High because a non-responsive layout makes the application unusable for the majority of mobile visitors, violating WCAG 2.2 SC 1.4.4 and directly suppressing conversion at launch.

Browser compatibility failures produce silent user exits: a feature that works in Chrome 130 may break in Safari 17 or Firefox ESR without any error visible to the developer. iOS Safari in particular has a distinct rendering engine (WebKit) that diverges from Chrome on CSS `gap` in flexbox, `position: sticky`, smooth scroll behavior, and new Web APIs — all common in modern framework templates. A project that passes QA in Chrome only can fail for a significant fraction of real users, particularly on mobile where Safari dominates iOS.

Why this severity: Medium because browser-specific rendering failures silently break the experience for a significant user segment — particularly iOS Safari — without producing errors visible in development.

Without error monitoring, production failures are invisible until a user emails you to complain — typically hours after the error first occurred. NIST SP 800-53 SI-11 (Error Handling) and NIST CSF 2.0 DE.CM (Continuous Monitoring) both establish error detection as a baseline operational control. Vibe-coded projects frequently ship with no monitoring configured because the development workflow never required it — but in production, unhandled exceptions in API routes, third-party SDK failures, and database connection errors all produce silent 500s that drain user trust with no signal to the developer.

Why this severity: High because the absence of error monitoring means every production failure — unhandled exceptions, API errors, database outages — is invisible until users report it, delaying response by hours.

CWE-778 and OWASP A09 both identify the absence of monitoring as a prerequisite for undetected failures. Uptime monitoring is the most basic layer: without an external service probing your application on a 30–60 second interval, you learn your app is down from user complaints — typically 15–60 minutes after the outage began. For a SaaS, every minute of undetected downtime is lost revenue and accumulated churn risk. NIST AU-6 (Audit Review, Analysis, and Reporting) requires continuous monitoring of system activity; uptime monitoring is the minimum viable implementation of this requirement for a public-facing service. The 'never skip' status of this check reflects that no deployed application is exempt — static sites go down too.

Why this severity: Critical because without external uptime monitoring, downtime goes undetected until users report it, maximizing the revenue and reputation impact of every outage.

A database without automated backups means a single corruption event, accidental deletion, or infrastructure failure permanently destroys every user record with no recovery path. NIST SP 800-53 CP-9 (System Backup) and ISO 27001:2022 A.8.13 mandate backup procedures as baseline controls. Supabase's free plan provides no automated backups — a fact that many vibe-coded projects never discover until after data loss. The absence of backups is not a theoretical risk: accidental table drops, failed migrations, and ransomware attacks all produce irreversible data loss without a tested restore procedure.

Why this severity: Critical because a single database corruption or accidental deletion with no backup means permanent, unrecoverable loss of all user data, violating NIST CP-9 and ISO 27001:2022 A.8.13.

Sandbox SMTP credentials (Ethereal, Mailtrap, Resend test keys starting `re_test_`) accept messages and return a success response, then silently discard them. Password-reset emails never arrive, signup confirmations vanish, and paying customers cannot recover locked accounts. Support inboxes fill with `I never got the email` complaints that look like user error but are actually a missing production key. GDPR and CAN-SPAM also require functional unsubscribe mail that a sandbox swallows.

Why this severity: High because broken transactional mail locks users out of their accounts and blocks revenue-critical flows.

Launching without analytics means the traffic from your Product Hunt post, Reddit thread, or paid campaign arrives invisible — you cannot tell whether anyone clicked, which pages they landed on, or where they dropped out of signup. Conversion funnels, referrer attribution, and bounce-rate signals are unrecoverable retroactively; if you add analytics a week later, that launch week stays a black hole. Product decisions default to vibes instead of data.

Why this severity: Medium because the blind spot is durable — missed traffic data cannot be backfilled once the event passes.

Seed data in a production database creates concrete security vulnerabilities: test accounts with known credentials like `test@example.com` / `password123` become valid login targets. CWE-798 (Use of Hard-coded Credentials) covers this class: any attacker who reads your seed script can authenticate to your production application as any seeded user. Beyond security, contaminated production data produces misleading analytics, corrupted user counts, and phantom records that break business logic assumptions — all problems that compound over time as real user data accumulates alongside test records.

Why this severity: High because seed accounts with known credentials in a production database are directly exploitable login targets per CWE-798, with no authentication barrier between attacker and live data.

Development `console.log` statements left in production code expose internal data structures, API response shapes, and occasionally user data or credentials in the browser's developer tools — visible to any technically literate user who opens DevTools. CWE-215 and CWE-532 both describe information exposure through debug output. Beyond security, dense console output in server-side code inflates log storage costs and buries legitimate error signals, making production incidents harder to diagnose. Console logs that capture user form data or authentication tokens are a compliance risk under GDPR data minimization requirements.

Why this severity: Low because the risk is primarily information disclosure to curious users with DevTools open, but console calls logging user data or tokens can escalate to a compliance issue under CWE-532.

Launching with sandbox or test-mode third-party integrations means the application appears functional but produces no real outcomes: Stripe test keys accept payment flows that charge nobody, email sandbox providers accept API calls that deliver nothing, and development OAuth apps reject real user tokens. CWE-798 and OWASP A05 cover misconfigured credentials as a security defect, but the business impact here is more immediate — users complete onboarding flows, enter payment details, and receive no confirmation, then churn. Every sandbox-mode integration is a silent conversion killer.

Why this severity: Medium because test-mode integrations process user actions with no real effect — payments, registrations, and emails silently fail — causing user churn and support volume without a direct security breach.

Every production deployment carries the risk of introducing a regression. Without a documented rollback mechanism, a bad deploy becomes a multi-hour incident requiring manual intervention with no defined process. NIST CSF 2.0 RC.RP (Recovery Plan Execution) and ISO 27001:2022 A.5.29 both treat recovery procedures as mandatory controls. The operational reality: Vercel instant rollback takes 30 seconds and requires no technical expertise; discovering you have no rollback path during a production incident adds panic on top of an already stressful situation.

Why this severity: Medium because lacking a rollback plan converts routine deployment regressions into open-ended manual incidents with no defined recovery path per NIST CSF RC.RP.

Without a web app manifest, Chrome and Edge suppress the install prompt, iOS Add-to-Home-Screen falls back to a screenshot icon, and Lighthouse flags the site on its PWA audit. Android users who do install the site get a low-resolution thumbnail in the launcher with the document title instead of your short_name, and the splash screen renders as a blank white page instead of branded `background_color` and `theme_color`.

Why this severity: Info because the feature gap affects only installed-app users, not core browser functionality.

Without a performance baseline before launch, any future deployment that regresses Core Web Vitals (LCP, CLS, INP) goes undetected until users notice the slowness. ISO 25010:2011 performance-efficiency.time-behaviour defines response time as a measurable quality attribute — not measuring it means you cannot detect regressions. Beyond technical debt, Lighthouse performance scores directly influence Google Search ranking via Core Web Vitals signals: an unmeasured, slow launch can suppress organic traffic from day one without any visible indicator to the developer.

Why this severity: Low because the absence of a performance baseline produces delayed detection of regressions rather than immediate harm, but it prevents the team from distinguishing intentional performance trade-offs from accidental degradation.

A hardcoded `http://localhost:3000/api` shipped to production either fails outright (CORS blocked, connection refused) or — worse — routes real user traffic to a developer laptop if that port happens to tunnel out via ngrok. Staging URLs like `api-staging.yourdomain.com` bypass production rate limits, log into the wrong database, and can leak real user PII into non-production systems outside your audit scope.

Why this severity: Info because most occurrences surface as loud failures during smoke testing, though silent wrong-environment routes remain possible.