Vibe coding launch checklist (15 checks before you ship)
Built a site with AI? This vibe coding launch checklist covers 15 checks, from mobile fit to exposed secrets, with how to check each one and a prompt to fix it.
Before you ship a vibe-coded site, check 15 things: mobile fit, the viewport tag, titles and descriptions, a share image, a favicon, a real 404 page, working forms, HTTPS on your own domain, speed, accessibility basics, analytics, privacy pages, broken links, logged-in pages and exposed secrets. Each one below says why it matters, how to check it, and gives you a prompt for Claude, ChatGPT, Cursor, Lovable, v0 or Bolt.
Most take five minutes. Number 15 is the one that can cost you real money, so don't skip it.
Looks right on every screen
1. It fits on real phone sizes
Why: most visitors arrive on a phone, and AI tools build and preview on a desktop-sized canvas.
Check: open your site at 360px (Galaxy S25), 402px (iPhone 17 Pro) and 440px (iPhone 17 Pro Max), plus a laptop. In doesitfit you want FITS on every screen, not TIGHT or SPILLING. Common causes and fixes are in 10 responsive mistakes in AI-built websites.
Make sure this site has no horizontal scrolling and no text touching the screen edge at 360, 402 and 440px wide. Fix causes, not symptoms: no overflow-x: hidden on html or body. Keep desktop unchanged.
2. The viewport meta tag is there
Why: without it, phones lay the page out about 980px wide and shrink it, so everything looks tiny.
Check: view the page source and search for viewport. You want width=device-width, initial-scale=1, and no user-scalable=no or maximum-scale=1. Details in the meta viewport tag.
Make sure every page has in the head, with nothing that blocks zooming.
Findable and shareable
3. Page titles and meta descriptions
Why: they're what people see in search results and browser tabs. AI starters often keep the template's title (Vite's React TypeScript starter is literally called "Vite + React + TS") or give every page the same one.
Check: open a few pages and read the tab titles. View source for <title> and <meta name="description">. Aim for a unique title of roughly 60 characters or fewer and a description of about 150–160 characters.
Give every page a unique, descriptive
(under 60 characters, main keyword first, brand last) and a <meta name="description"> of about 150–160 characters that says what the page offers. List them so I can review.</p> </blockquote> <h3 id="4-a-social-share-image-og-image">4. A social share image (og:image)</h3> <p><strong>Why:</strong> when someone pastes your link in WhatsApp, iMessage, Slack or LinkedIn, the preview card is your first impression. No image means a sad grey box.</p> <p><strong>Check:</strong> send your link to yourself in a chat app. In the source, look for:</p> <pre><code class="language-html"><meta property="og:title" content="Your page title"> <meta property="og:description" content="One sentence about the page"> <meta property="og:image" content="https://www.example.com/og.png"> <meta name="twitter:card" content="summary_large_image"> </code></pre> <p>The image URL must be absolute (starting with <code>https://</code>), and 1200×630 is the usual size.</p> <blockquote> <p>Add Open Graph and Twitter card tags to every page: og:title, og:description, og:url, og:image (absolute URL, 1200×630) and twitter:card summary_large_image. Create a simple og.png with the site name and tagline if none exists.</p> </blockquote> <h3 id="5-a-favicon">5. A favicon</h3> <p><strong>Why:</strong> it shows in tabs, bookmarks and on home screens. The framework's default logo says "unfinished".</p> <p><strong>Check:</strong> look at the browser tab. For iPhone home screens you also want a 180×180 <code>apple-touch-icon</code>:</p> <pre><code class="language-html"><link rel="icon" href="/favicon.ico" sizes="32x32"> <link rel="icon" href="/icon.svg" type="image/svg+xml"> <link rel="apple-touch-icon" href="/apple-touch-icon.png"> </code></pre> <blockquote> <p>Replace the default favicon with one based on my logo: favicon.ico (32×32), icon.svg and a 180×180 apple-touch-icon.png, linked in the head of every page.</p> </blockquote> <h3 id="6-a-real-404-page">6. A real 404 page</h3> <p><strong>Why:</strong> typos and old links happen. A helpful 404 page keeps the visitor; a blank screen loses them. It should also send a real 404 status, not 200, or search engines may treat the error page as a real page (a "soft 404").</p> <p><strong>Check:</strong> visit <code>/this-does-not-exist</code>, then check the status:</p> <pre><code class="language-bash">curl -sI https://www.example.com/this-does-not-exist | head -n 1 </code></pre> <p>You want to see <code>404</code>. Single-page apps that send every URL to <code>index.html</code> often answer 200.</p> <blockquote> <p>Add a friendly 404 page with a link home and to the main sections, and make sure unknown URLs return HTTP status 404, not 200. Tell me what to change in the hosting config if needed.</p> </blockquote> <h2 id="works-and-loads-fast">Works and loads fast</h2> <h3 id="7-forms-work-and-show-errors">7. Forms work and show errors</h3> <p><strong>Why:</strong> a contact or signup form that silently fails is worse than no form.</p> <p><strong>Check:</strong> submit it empty, with a broken email, and for real. Does each error appear next to the right field, in words? Does the real one arrive in your inbox or database? Do phones show the right keyboard (<code>type="email"</code>, <code>type="tel"</code>)?</p> <blockquote> <p>Check every form: visible labels, the right input types, clear error messages next to each field, a success message, a disabled button while sending, and basic spam protection. Tell me where submissions go and how I can test that they arrive.</p> </blockquote> <h3 id="8-https-and-your-custom-domain">8. HTTPS and your custom domain</h3> <p><strong>Why:</strong> browsers mark plain http pages "Not secure", and one address is better for users and search engines than four.</p> <p><strong>Check:</strong> <code>http://</code>, <code>https://</code>, <code>www.</code> and bare-domain versions should all end up at one https address:</p> <pre><code class="language-bash">curl -sI http://example.com | grep -iE '^(HTTP|location)' </code></pre> <p>You want a 301 or 308 redirect to your https address.</p> <blockquote> <p>Walk me through connecting my custom domain on my host, forcing HTTPS, and redirecting www and non-www to one canonical https address with a permanent redirect.</p> </blockquote> <h3 id="9-page-speed-basics">9. Page speed basics</h3> <p><strong>Why:</strong> phones on mobile data are slow, and big images are the usual culprit.</p> <p><strong>Check:</strong> run <a href="https://pagespeed.web.dev/" rel="noopener">PageSpeed Insights</a> on the mobile tab. Google's "good" Core Web Vitals thresholds are LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less (<a href="https://web.dev/articles/vitals" rel="noopener">web.dev: Web Vitals</a>). Look for 3000px photos in 400px slots and images that load before they're needed.</p> <blockquote> <p>Make images fast: resize to the largest size they're displayed at (with srcset for different screens), use WebP or AVIF, add width and height attributes, and add loading="lazy" to images below the fold, but not to the hero image.</p> </blockquote> <div class="cta-box"> <p class="cta-title h">Does your site fit?</p> <p>Paste your address (or <span class="mono">localhost:3000</span>). doesitfit shows it on real screen sizes at once and tells you, bluntly, where it spills.</p> <form class="cta-form" data-ids=""> <label class="sr-only" for="cta-4g13pp">Your site</label> <input id="cta-4g13pp" type="text" inputmode="url" autocomplete="url" autocapitalize="off" spellcheck="false" placeholder="yoursite.com or localhost:3000"> <button class="btn btn-primary" type="submit">Try it on <svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.5" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true" focusable="false"><path d="M5 12h14"/><path d="M13 6l6 6-6 6"/></svg></button> </form> <p class="small">Free, no sign-up. Or <a href="/connect">ask Claude, ChatGPT or Codex to check it</a>.</p> </div> <h2 id="usable-measurable-and-tidy">Usable, measurable and tidy</h2> <h3 id="10-accessibility-basics">10. Accessibility basics</h3> <p><strong>Why:</strong> keyboard users, screen reader users and people who zoom are real visitors, and the basics are cheap.</p> <p><strong>Check:</strong> every meaningful image has <code>alt</code> text (decorative ones get <code>alt=""</code>). Body text contrast is at least 4.5:1, large text 3:1 (WCAG AA). Press Tab through the page: can you see where you are and reach everything? Pinch-zoom works on a phone. Chrome's Lighthouse accessibility audit catches plenty more.</p> <blockquote> <p>Do an accessibility pass: alt text on meaningful images, colour contrast at WCAG AA, visible focus styles, everything reachable and usable with a keyboard, labels on form fields and icon buttons, and zoom not blocked.</p> </blockquote> <h3 id="11-analytics">11. Analytics</h3> <p><strong>Why:</strong> otherwise you'll never know if anyone came, or which page they left from.</p> <p><strong>Check:</strong> install your analytics, visit from your phone, and see the visit appear. Make sure your own visits are filtered out, and that key actions like signups are tracked.</p> <blockquote> <p>Add [privacy-friendly analytics tool] to every page, track signups and contact form submissions as events, and show me how to exclude my own visits.</p> </blockquote> <h3 id="12-privacy-and-legal-pages-where-required">12. Privacy and legal pages where required</h3> <p><strong>Why:</strong> if you collect personal data (emails, form submissions, analytics cookies, payments), many countries expect you to say what you collect and why, and in the EU and UK non-essential cookies generally need consent first. This isn't legal advice: check what applies where you and your visitors are.</p> <p><strong>Check:</strong> is there a privacy page linked in the footer, and does it match what the site actually does?</p> <blockquote> <p>List every kind of personal data this site collects or sends to third parties (forms, analytics, cookies, embeds, payment, auth), with the file where it happens. I'll use it to write or check my privacy policy.</p> </blockquote> <h3 id="13-no-broken-links">13. No broken links</h3> <p><strong>Why:</strong> AI loves placeholder links: <code>href="#"</code>, "/about" pages that were never built, footer links to nowhere.</p> <p><strong>Check:</strong> click every link in the nav and footer. Crawl the whole site with <code>npx linkinator https://www.example.com --recurse</code> or the <a href="https://validator.w3.org/checklink" rel="noopener">W3C Link Checker</a>, and search your code for <code>href="#"</code>.</p> <blockquote> <p>Find every link that goes nowhere: href="#", links to pages that don't exist, and buttons without an action. List them and fix or remove each one.</p> </blockquote> <h2 id="behind-the-login-and-under-the-hood">Behind the login and under the hood</h2> <h3 id="14-logged-in-pages-are-checked-too">14. Logged-in pages are checked too</h3> <p><strong>Why:</strong> dashboards and settings are what paying users see every day, and they get the least testing.</p> <p><strong>Check:</strong> go through every logged-in page on a phone-sized screen. doesitfit's <strong>Site login</strong> helps: log in to your site in a normal window, come back, and the screens reload showing the logged-in view. Live sites usually keep their login away from other websites (the safe default), so check your <code>localhost</code> copy; if you're still logged out there, the Site login box has a fix prompt that only changes development settings.</p> <blockquote> <p>Go through every page behind the login and apply the same mobile rules as the public pages: no horizontal scrolling at 360px, tables that scroll inside their own box, and buttons at least 44×44px.</p> </blockquote> <h3 id="15-secrets-are-not-in-the-frontend">15. Secrets are not in the frontend</h3> <p><strong>Why:</strong> anything the browser downloads is public. Secret keys in your JavaScript get found and abused, and the bill is yours.</p> <p><strong>Check:</strong> environment variables starting with <code>NEXT_PUBLIC_</code> or <code>VITE_</code> are built into the browser code on purpose, so never put secrets in them. Open DevTools on your live site, search the JavaScript files for key prefixes like <code>sk_live_</code> (Stripe), <code>sk-proj-</code> (OpenAI) and <code>sk-ant-</code> (Anthropic), and for <code>secret</code> and <code>service_role</code>, and make sure <code>.env</code> files aren't in a public repo. With Supabase, the anon (publishable) key is meant to be public but is only safe with Row Level Security on every table; the service_role (secret) key must never reach the browser.</p> <blockquote> <p>Audit this project for exposed secrets. List every API key or token and where it's used, move anything secret to server-side code or environment variables without a public prefix, check that .env is in .gitignore, and if I use Supabase, confirm Row Level Security is on for every table. Tell me which keys I should rotate.</p> </blockquote> <h2 id="before-you-press-publish">Before you press publish</h2> <ul> <li>Do the two that can hurt you first: <strong>15</strong> (secrets) and <strong>7</strong> (forms).</li> <li>Then the two everyone sees: <strong>1</strong> (fits on phones) and <strong>4</strong> (share image).</li> <li>The rest take an afternoon, together.</li> </ul> <p>For the mobile part in depth, see <a href="/blog/make-ai-website-mobile-friendly">make your AI website mobile friendly</a>. To check without a phone in your pocket, see <a href="/blog/test-website-on-mobile-without-phone">how to test your website on mobile without a phone</a>, and browse every screen size in <a href="/devices">/devices</a>.</p> </div> <section class="section" aria-labelledby="faq-title"><h2 id="faq-title">Questions people ask</h2><div class="faq"><details><summary><span class="q">What should I check before launching a website built with AI?</span></summary><div class="faq-body"><p>Check that it fits on real phones, has page titles, descriptions and a share image, that forms work, that it runs on HTTPS on your own domain, loads fast and works with a keyboard. Above all, make sure no secret keys are in the frontend code.</p></div></details><details><summary><span class="q">How do I know if my API keys are exposed?</span></summary><div class="faq-body"><p>Open your live site, look through the page source and the JavaScript files in DevTools, and search for your key prefixes and words like secret or service_role. Anything the browser downloads is public.</p></div></details><details><summary><span class="q">Do I need a privacy policy for a small website?</span></summary><div class="faq-body"><p>If you collect personal data, such as emails, form submissions or analytics cookies, the law in many places expects one. This isn't legal advice, so check the rules where you and your visitors are.</p></div></details><details><summary><span class="q">What size should an og:image be?</span></summary><div class="faq-body"><p>1200 by 630 pixels is the widely used size for link previews. Use an absolute URL starting with https:// and keep important text away from the edges.</p></div></details></div></section> </article> <aside class="toc" aria-label="On this page"><b>On this page</b><ol><li><a href="#looks-right-on-every-screen">Looks right on every screen</a></li><li><a href="#findable-and-shareable">Findable and shareable</a></li><li><a href="#works-and-loads-fast">Works and loads fast</a></li><li><a href="#usable-measurable-and-tidy">Usable, measurable and tidy</a></li><li><a href="#behind-the-login-and-under-the-hood">Behind the login and under the hood</a></li><li><a href="#before-you-press-publish">Before you press publish</a></li></ol></aside> </div> <section class="section" aria-label="More guides"><h2>Keep reading</h2><ul class="post-grid"><li><a class="post-card" href="/blog/ai-website-responsive-mistakes"><b>10 responsive mistakes in AI-built websites (and fixes)</b><span>AI tools build great desktop pages and wobbly phone ones. The 10 responsive mistakes AI-built websites make most, how to spot each one, and a prompt to fix it.</span><small>AI building · 8 min read</small></a></li><li><a class="post-card" href="/blog/test-website-with-claude-chatgpt-mcp"><b>Check your website from Claude, ChatGPT or Codex (MCP)</b><span>Connect doesitfit to Claude, ChatGPT, Codex or Cursor with MCP and ask whether your site fits on an iPhone. Setup for each app, example prompts and the limits.</span><small>AI building · 7 min read</small></a></li><li><a class="post-card" href="/blog/responsive-design-prompts"><b>Copy-paste prompts to fix responsive design with AI</b><span>Copy-paste prompts to fix responsive design with Claude, ChatGPT, Cursor, Lovable, v0 or Bolt: sideways scroll, menus, tables, 100vh, iPhone form zoom and more.</span><small>AI building · 9 min read</small></a></li></ul></section> </div> </main> <div class="site-footer-links"><div class="wrap footer-cols"> <nav aria-label="Try it"><h2>Try it</h2><ul><li><a href="/app">Open the app</a></li><li><a href="/whats-my-viewport">What’s my viewport?</a></li><li><a href="/connect">Use with your AI</a></li><li><a href="/#how">How it works</a></li></ul></nav> <nav aria-label="Devices"><h2>Devices</h2><ul><li><a href="/devices/iphone">iPhone</a></li><li><a href="/devices/samsung-galaxy">Samsung Galaxy</a></li><li><a href="/devices/google-pixel">Google Pixel</a></li><li><a href="/devices/ipad">iPad</a></li><li><a href="/devices/macbook">MacBook</a></li><li><a href="/devices/windows-laptops">Windows laptops</a></li><li><a href="/devices/monitors">Monitors</a></li><li><a href="/compare">Compare devices</a></li><li><a href="/devices">All 123 devices</a></li></ul></nav> <nav aria-label="Screen sizes"><h2>Screen sizes</h2><ul><li><a href="/screen-sizes">Most common sizes</a></li><li><a href="/widths">All widths</a></li><li><a href="/screen-sizes/402x874">402 × 874</a></li><li><a href="/screen-sizes/390x844">390 × 844</a></li><li><a href="/screen-sizes/360x780">360 × 780</a></li><li><a href="/screen-sizes/412x915">412 × 915</a></li><li><a href="/screen-sizes/1470x956">1470 × 956</a></li><li><a href="/screen-sizes/1536x864">1536 × 864</a></li><li><a href="/screen-sizes/1920x1080">1920 × 1080</a></li></ul></nav> <nav aria-label="Guides"><h2>Guides</h2><ul><li><a href="/blog/ai-website-responsive-mistakes">10 responsive mistakes in AI-built websites</a></li><li><a href="/blog/100vh-mobile-fix">100vh on mobile is broken</a></li><li><a href="/blog/test-website-with-claude-chatgpt-mcp">Check your website from Claude, ChatGPT or Codex</a></li><li><a href="/blog/container-queries-vs-media-queries">Container queries vs media queries</a></li><li><a href="/blog/responsive-design-prompts">Copy-paste prompts to fix responsive design with AI</a></li><li><a href="/blog/device-pixel-ratio-explained">Device pixel ratio</a></li><li><a href="/blog">All guides</a></li></ul></nav> </div></div> <footer class="site-footer"> <div class="wrap footer-inner"> <a class="logo logo-sm" href="/">doesitfit<span>.lol</span></a> <p class="footer-note">Device data researched September 2026</p> <a class="footer-link" href="/app">Open app <svg width="18" height="18" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.5" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true" focusable="false"><path d="M5 12h14"/><path d="M13 6l6 6-6 6"/></svg></a> </div> </footer> <script src="/content.js" defer></script> <script src="/track.js" defer></script> </body> </html>