# Maintaining over Building (Brian Coords - Woo) > [!question] Lingering Questions > - Whether vibe-coding genuinely can't handle complex e-commerce/publishing, or just can't *yet*, is asserted as intuition ("I'm not so sure"), honestly flagged as such — the complexity frontier may be moving. > - The 90%-abandoned and revert-to-Linear examples are memorable illustrations from a maintainer motivated to make this exact case — worth keeping as illustrations, not as data. > - Is Woo's "maintenance mode" quarter a durable strategy or a one-quarter narrative? Worth revisiting once the backlog-clearing quarter concludes. > [!tip] Article Ideas > - Three-source cluster in the same reading batch, same claim from different chairs: Coords (maintainer), MemberPress (market-share), and any wp2shell-style security analysis (security). "Generating software is cheap; sustaining it safely on a huge install base is the game." A synthesis-note candidate worth drafting. > - "Maintenance capacity is vulnerability-surface capacity" — pair with any core-security-response framing for an OSPO/security-writing angle. > [!link] Cross Reference > - [[3. Resources/MOCs/Open Source Governance MOC]] — maintenance labor and prestige is a recurring vault theme (see [[3. Resources/Permanent Notes/Maintenance Is Most of the Work but Gets No Prestige]]) > - [[3. Resources/Literature Notes/WordPress Lost Market Share (MemberPress)]] — same reading batch, same claim (generation is cheap, sustaining safely at scale is the game) from the market-share angle rather than the maintainer's chair > [!quote] Vocabulary > - none flagged — the piece uses plain, non-specialized vocabulary throughout ## Metadata - Source: [[3. Resources/Readwise/Articles/Maintaining over Building]] - Author: Brian Coords (Woo/Automattic engineer) - Type: article - URL: https://www.briancoords.com/maintaining-over-building/ ## Author's thesis Maintenance is the hard, unglamorous, non-optional work that AI doesn't erase — it may even increase it, by making it trivial to generate more code that then has to be maintained. When software runs on millions of live sites, caution is not timidity, it's what makes software last; a mature platform is better served by "one big thing done well, plus a thousand small fixes" than by feature-per-day velocity. ## Key arguments (≤3) 1. **Generation is cheap; sustaining software is the hard part** — Coords's own self-implicating data point: "90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust." He's not exempting himself, which is what gives the piece its credibility, and it's the same abandonment shape MemberPress cites for vibe-coded startups from a vendor-estimate angle rather than personal experience — two independent roads to the same figure. 2. **Caution scales with install base, not timidity** — the cost of a mistake scales with how many live sites run the code; a viral tweet about a team that reverted from a vibe-coded internal tool back to Linear because maintaining it "was taking away from their actual work's bandwidth" is the concrete failure mode: the build was cheap, the upkeep wasn't. 3. **The market split is a reasonable bet, not a proof**: vibe-coding will likely take share for small sites and landing pages; Coords is honestly uncertain ("I'm not so sure") whether it can handle something as complex as publishing or e-commerce — the honest hedge is better than false certainty, and the piece discloses Woo itself is spending the quarter in maintenance mode clearing its GitHub backlog. ## Claim atoms ### Generation is cheap; sustaining software is the hard part > [!quote] ID:rw_pending > Meanwhile 90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust. The whole thesis in one self-aware line — credible because Coords is Exhibit A rather than pointing at others. ### Caution scales with install base, not timidity > [!quote] ID:rw_pending > when your software is run, extended, modified, and personalized on millions of live websites, you still have to be cautious. The opening, load-bearing frame: a mistake's blast radius scales with the install base, so mature-platform velocity should differ from a startup's. ### One big thing well, plus a thousand small solid fixes > [!quote] ID:rw_pending > Pick one big thing. Do it really well. Spend the other eleven months making the thousand small things people actually touch every day feel solid. Borrowed from MacSparky, endorsed as the strategy: feature velocity is a marketing metric, perceived quality is a retention metric, and they pull against each other. ## Permanent candidates - **Cheap generation raises the maintenance bill, it doesn't lower it** — **already captured** by the existing [[3. Resources/Permanent Notes/Cheap Generation Raises the Total Maintenance Bill]] note (created 2026-07-27, same origin article) — connected, not duplicated. - **Caution scales with install base, not timidity** — a distinct, non-duplicate angle from the same source: mature-platform velocity should differ from a startup's because blast radius scales with install base. Promoted below. ## Processing checklist - [x] Verify no existing Literature Note covers this doc (checked, none found — the existing "Custom product templates for block themes (Brian Coords)" note is a different article) - [x] Extract claim atoms from the existing deep-read - [x] Confirm the Permanent note for the primary claim already exists — connected, not recreated - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — maintenance labor, prestige, and funding is a recurring governance question - [[3. Resources/Permanent Notes/Cheap Generation Raises the Total Maintenance Bill]] — the primary claim this source supports, already captured as a Permanent note - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — applies-in: the MOC lists this note under Synthesis additions (2026-08-16 — maintenance and durability).