# Vibe-coding a landing page from scratch is completely pointless > [!question] Lingering Questions > - The managed-deployment middle option (Vercel, Netlify, Cloudflare Pages) defeats part of the interview's argument and goes unmentioned — is that an oversight or a framing choice by a website-builder-adjacent speaker? > - Neither participant mentions accessibility once, in an interview about generating whole websites. What does that omission say about the current vibe-coding conversation? > [!tip] Article Ideas > - What platforms absorb invisibly (CDN, media pipeline, permissions, certificates) — using this interview's blind spot as the hook. > - A defaults comparison: vibe-coded vs. builder vs. managed WordPress landing pages on CDN, image formats, lazy loading, security headers. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/A Vibe-Coded Demo Is Easier to Ship Than a Vibe-Coded Product]] > - [[3. Resources/Permanent Notes/Personal Fit and Shareability Trade Off in Vibe-Coded Software]] > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Bib capsule TechRadar interview about the impact of vibe coding on website building — the interviewed speaker represents a website-builder platform and argues vibe coding overcomplicates simple sites while suiting micro-SaaS. ## Author's thesis Vibe coding is well-suited to building small, functional software (micro-SaaS) but poorly suited to landing pages and simple sales material, because platforms absorb operational work — CDN, media handling, permissions, certificates — that a generated site leaves undone. The likely equilibrium is hybrid: generate the first draft with AI, then refine through a direct-manipulation interface, because prompt-based iteration is structurally slower than clicking for small, positional changes. ## Key arguments (≤3) 1. **The core claim is scoped by task type, not asserted globally**: vibe coding suits micro-SaaS, not landing pages. (Note: the speaker sells a competing product — a website builder.) 2. **The security argument has a real decision boundary**: risk becomes near-certain once a generated site starts handling orders, submissions, or accumulated user data. 3. **The time-cost argument is structural, not incidental**: prompt-based iteration costs roughly a minute per small change vs. seconds in a direct-manipulation interface — a property of the interaction model, not a temporary quality gap. ## Claim atoms ### Vibe coding suits micro-SaaS, not landing pages > [!quote] ID:rw_01kyq8jvyqs09s44r9eaj8kf1b > vibe code is excessive for most sites. It's brilliant for building micro-SaaS. But for building landing pages or simple sales material? Absolutely not The headline claim, scoped usefully by task type rather than asserted globally. The speaker sells a competing product (a website builder), which should temper how much weight this carries unverified. ### Data handling turns generated-site risk into certainty > [!quote] ID:rw_01kyq8k3hksnhwnzh6k68ym833 > once you start processing orders or submissions inside it, or accumulating user data, that puts your service at serious risk, and the risk is a certainty A usable decision boundary rather than a blanket warning, though the "certainty" quantifier is unevidenced and should be read as emphasis. ### Prompt iteration costs a minute where interfaces cost seconds > [!quote] ID:rw_01kyq8ken5g3m39crhec9yak9c > something as trivial as recolouring a button: five seconds in the interface, whereas here you write a prompt, it thinks, it regenerates the style — that's a minute The most transferable observation in the article: the cost is structural to the interaction model, not a temporary quality problem. Applies to any AI feature layered over an existing direct-manipulation UI. ### Generate the first draft, refine through the interface > [!quote] ID:rw_01kyq8knsw9p0tyqj513xmwdxa > we see the future in synergy: you get the first result with vibe code, then refine the details through the interface The predicted equilibrium, and a concrete design target for any WordPress or Gutenberg AI feature. ## Permanent candidates - **A platform's real product is the work it absorbs, not the interface it shows** — promoted below. - **Generation wins the first draft and loses every revision after it** — promoted below. ## Processing checklist - [x] Ported from existing deep-read (Refactor Appendix) - [x] Checked for duplicate Permanent notes — related notes found and linked, no exact duplicates - [x] Connected into MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] - [ ] Run the defaults comparison (vibe-coded / builder / managed WordPress) to settle the article's implicit empirical claims ## Metadata - Source: [[3. Resources/Literature Notes/Vibe-coding a landing page from scratch is completely pointless]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — the platform-vs-generation framing bears directly on build-vs-buy product decisions - [[3. Resources/Permanent Notes/A Vibe-Coded Demo Is Easier to Ship Than a Vibe-Coded Product]] — extends; same underlying pattern (impressive generation, unproven durability) applied to a different production stage