It's Time to Go Bigger  🔗 **Source:** [It's Time to Go Bigger](https://www.youtube.com/watch?v=WBT-z_-OPhw#transcript) > [!note]+ Document Notes > tags: [ai-development, software-architecture, developer-tools, boil-the-ocean, horizontal-vs-vertical, indie-hacking] > author: Theo Browne > source: Theo - t3.gg (YouTube) > reference: https://www.youtube.com/watch?v=WBT-z_-OPhw > date created: 2026-06-20 12:00 > > # 🏷️ Title: It's time to go bigger > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Theo - t3.gg (YouTube channel)](https://www.youtube.com/@t3dotgg) - [CascadiaJS](https://cascadiajs.com) (the talk this video expands on) - [WorkOS / AuthKit + OMD standard](https://workos.com) (sponsor) - [Vercel](https://vercel.com), [AWS](https://aws.amazon.com), [GitHub Pages](https://pages.github.com) - [T3 Stack](https://create.t3.gg), [tRPC](https://trpc.io), [UploadThing](https://uploadthing.com) ## 📝 Summary - **What happened.** Theo Browne, opinionated dev-culture streamer (T3 Stack, tRPC, UploadThing founder), expands a CascadiaJS talk into a manifesto: AI has made building software so cheap that the old startup playbook — pick one vertical and go deep — is obsolete. He argues developers should now "boil the ocean," building deliberately mediocre but functional all-in-one *horizontal* products that previously made no economic sense. He demos his in-progress platform, LakeBed ("the shitty cloud for shitty apps"), spinning up 10 working apps in ~8 minutes. - **Why it matters.** It's a contrarian reframe aimed at engineers feeling fear/redundancy as AI compresses hundreds of hours into tens. Theo's thesis: the response to "my work can be done in 15 hours now" isn't despair, it's *doing more* — attempting things that were uneconomical before. - **Key stakeholders.** Indie hackers and solo builders, startup founders weighing build vs. risk, engineers fearing displacement, cloud/dev-tool incumbents (AWS, Vercel) whose horizontal moats Theo says are now contestable. - **Risks and tradeoffs.** The "shitty horizontal" play trades depth/quality for breadth and speed; security is explicitly punted ("maybe I'll have a model that's allowed to do security stuff"); the elastic-demand and "the wall is far" claims are demonstrated on toy apps, not production scale; survivorship framing (his own past success) colors the optimism. - **Bottom line.** Don't automate the work you already did — use AI to attempt the work that didn't make sense before. Pick an idea that "sounds like it shouldn't be possible" and push until you hit the wall; Theo bets the wall is farther than you think. ## 📖 Main Content - **The historical analogy: the cloud.** Theo grounds the argument in a prior platform shift. Pre-cloud, building was capital-intense: you provisioned physical servers and had to predict traffic accurately, so experimentation was expensive and risky. AWS made experimentation cheap — start small, scale to "Amazon scale" without an Amazon-tier team. AI, he argues, is the same kind of shift, not a job-killer. - **The human cost of pre-AI experimentation.** Beyond money, hiring teams to build the wrong thing is "soul crushing" — he references having laid off a team before, and how that social cost steers founders away from big bets. AI lowers that human risk because code-writing got cheap. - **The Salesforce / feature-spectrum argument.** Most enterprise software (Salesforce) has a small core everyone uses and a vast long tail that <1% need. Competing historically required building the whole long tail (a "suicide mission") because customers won't switch if even 2 of their 12 needed features are missing. AI changes the math on covering breadth. - **Horizontal vs. vertical (the core diagram).** Software has *horizontal range* (how many categories you cover — frontend, hosting, DB, security) and *vertical depth* (how many features per category). Startups historically had to pick one vertical and go deep (Vercel vs. AWS: full-stack web hosting done so well "it feels bad to use anything else"). Theo's claim: AI makes the wide *range* feasible, and depth is "much less your problem" if you architect so users can extend the parts you don't cover. - **From "glue" to "sledgehammer."** Theo's career was building glue between verticals (tRPC for back/front, UploadThing for file upload). He realized fixing one thin seam just exposes the next. So with LakeBed he stopped gluing and rebuilt everything: his own framework, runtime, bundler (no filesystem needed), cloud platform, and database primitive — "the code itself is the instructions for the deployment." - **The LakeBed demo.** He spun up Cursor agent (Composer 2.5) plus Claude Code and built 10 apps from scratch in ~8 minutes — to-do list, poll arena, recipe box — all with real-time sync across tabs/users and one-click Google sign-in baked into the platform. The point: these "shitty apps" that shouldn't get thousands of users were previously too much assembly work to bother publishing. - **The "hit the wall" experiment.** Theo says he didn't build LakeBed to ship and succeed; he built it to find where "boiling the ocean" breaks down — and it hasn't yet, which is what excites (and unsettles) him. - **The call to action.** The industry isn't building big enough; developers automate old work instead of attempting new kinds of work. Find an idea "in the back of your mind" that sounds impossible and push until the wall. A follow-up video will pitch ideas he wishes others would build. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=0) The fear framing - Software-building has changed fundamentally; many engineers feel fear as hundreds of hours collapse into 10–15. - Theo's reframe: the upside is *things we can now create that didn't make sense to create before.* #### ⏱️ [00:00:33](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=33) "There is a way to do more" - The video is about *how we think* when using these tools, not specific tools/technologies. - Based on a CascadiaJS talk; meant as a "context builder" for a follow-up ideas video. #### ⏱️ [00:01:06](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=66) Sponsor: WorkOS / OMD - WorkOS's new open standard OMD lets agents register for a service on a user's behalf (initial partners Cloudflare, Firecrawl); one-click enable via AuthKit, with a "user-claimed" flow for safety. #### ⏱️ [00:02:41](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=161) The cloud as precedent - "It's time to rethink everything." The biggest prior shift was the cloud — it changed how software is built, architected, and how teams are hired/structured. #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=192) Life before the cloud - Capital-intense: provision real machines, predict traffic accurately. Under-predict → crash; over-predict → wasted money. Experimentation was inherently expensive. #### ⏱️ [00:04:17](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=257) Post-cloud: start small, scale trivially - AWS let people reach Amazon-scale without Amazon-tier teams or buying power; new categories of software (Slack, Salesforce) became viable. #### ⏱️ [00:05:55](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=355) The soul-crushing cost of bad bets - Hiring people to build the wrong thing, then laying them off, "[__] sucks" and steers founders away from big bets. AI lowers that human risk. #### ⏱️ [00:07:00](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=420) Everything we believed is no longer true - Speccing, incident reporting, team structure, hiring, release cadence — all assume expensive code. Time to challenge what should/shouldn't be built. #### ⏱️ [00:08:04](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=484) Salesforce feature spectrum - Small core everyone needs; huge tail <1% need. 95% of customers use ~5% of features, but the variety in that 5% made competing a money-burning suicide mission. #### ⏱️ [00:10:46](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=646) Horizontal range vs. vertical depth - Range = categories covered (hosting, DB, security); depth = features per category. GitHub Pages vs. Vercel: both host, Vercel goes deeper; need a DB and you go horizontal to another provider. #### ⏱️ [00:12:23](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=743) Why you couldn't beat AWS - AWS has *something* in every vertical but not every feature in each. Vercel won by picking full-stack web hosting and making it so good "it felt bad to use anything else." #### ⏱️ [00:13:28](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=808) What changed: go wide, depth is the user's problem - Now it makes sense to cover the whole range; architect so users extend the parts you don't solve. Anecdote: someone built image-sharing on his DB-only product with no file storage by breaking up binaries in the database. #### ⏱️ [00:14:33](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=873) LakeBed — "the shitty cloud for shitty apps" - Built to publish the pile of half-finished local apps without the annoying glue (auth tokens, inference, DB, preview envs). #### ⏱️ [00:15:38](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=938) Build vs. deploy time inversion - "Marker thing" (stream-topic tracker): ~30–40 hrs to build, ~3 hrs to deploy — deploy was <10% of time, so it didn't matter. Now he can build it in 30 min but deploy still takes as long. That gap "pissed me off." #### ⏱️ [00:16:11](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=971) Shu — the Google OAuth broker - Built Shu to abstract OAuth: no dashboard, copy two lines of code. Was going to be his next big project; may open-source it after a security-allowed model can vet it. #### ⏱️ [00:17:17](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1037) Living in the margins / glue era - He always spent his time on the seams between verticals (tRPC, UploadThing in 2023). But fixing one glue layer just exposes the next — an endless margin. #### ⏱️ [00:18:54](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1134) Sledgehammer: reinvent everything - Instead of more glue, LakeBed reinvents framework, runtime, cloud platform, bundler (no filesystem), and DB primitive. "The code itself is the instructions for the deployment." Agents are improving it in the background. #### ⏱️ [00:19:27](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1167) The boil-the-ocean mindset - A "shitty but functional in every category" horizontal play now makes sense because it can finally function where it previously couldn't. #### ⏱️ [00:20:00](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1200) Demo: 10 apps in ~8 minutes - Cursor agent (Composer 2.5) + Claude Code built 10 apps from scratch; to-do, poll arena, recipe box; real-time sync across tabs and users, one-click Google sign-in — all baked into the platform. #### ⏱️ [00:21:41](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1301) Hitting the wall on purpose - He built it to find where boiling the ocean fails — and "it somehow hasn't." The further he goes, the more real it feels, which messes with his brain. #### ⏱️ [00:22:13](https://www.youtube.com/watch?v=WBT-z_-OPhw&t=1333) Closing call: build bigger - The industry isn't building big enough; devs automate old work instead of enabling new work. Find the idea that "sounds like it shouldn't be possible" and push until the wall — "I think you'll be surprised just how far off that wall is." Follow-up ideas video promised. "Peace nuts." ## 📚 References - [Theo - t3.gg (channel)](https://www.youtube.com/@t3dotgg) - [CascadiaJS conference](https://cascadiajs.com) — the source talk - [WorkOS — AuthKit & OMD](https://workos.com) — sponsor; agent-registration standard with Cloudflare/Firecrawl - [Vercel](https://vercel.com) / [AWS](https://aws.amazon.com) / [GitHub Pages](https://pages.github.com) — the horizontal/vertical examples - [T3 Stack](https://create.t3.gg), [tRPC](https://trpc.io), [UploadThing](https://uploadthing.com) — Theo's prior "glue" projects - LakeBed / Shu — Theo's in-progress platform and OAuth broker (not yet public) ## 🗣️ Paraphrase - Software-building changed fundamentally and fast; many engineers read this as a threat, but the real opportunity is creating things that were previously uneconomical. - We've lived through this before: the cloud let small teams reach Amazon scale without Amazon resources, and AI is an analogous shift, not an extinction event. - Pre-cloud and pre-AI, experimentation was financially and *humanly* costly — bad bets meant layoffs — which deterred ambitious attempts. - The old winning strategy was to pick one vertical and go very deep, because covering AWS's full range was a suicide mission; AI flips that, making horizontal breadth feasible while users self-serve depth. - Theo's career was building "glue" between verticals, but each fix exposed the next seam, so with LakeBed he reinvented the whole stack instead. - LakeBed is a deliberately mediocre "shitty cloud for shitty apps" that can spin up 10 working, syncing, authenticated apps in minutes. - He built it to find where "boiling the ocean" breaks down, and it hasn't yet — evidence the new ceiling is much higher than expected. - The call to action: stop automating yesterday's work; attempt the impossible-sounding idea and push until you hit a wall that's farther away than you fear. ## 📰 Newsletter **Stop gluing. Start boiling the ocean.** Theo Browne's latest is a pep talk dressed as a strategy memo — and there's a thread here for the WordPress crowd too. His core move: the cloud once turned "rent servers from the company you buy groceries from" into a normal sentence, and AI is doing the same thing to *what we even bother building.* The old rule was pick one vertical and go deep (think Vercel beating AWS at full-stack hosting, not at everything). Theo says AI inverts it: now you can go *wide* — build a "shitty but functional" all-in-one — and let users extend the depth they need. His demo, LakeBed, the self-described "shitty cloud for shitty apps," spun up ten working apps with real-time sync and Google login in about eight minutes. The WordPress parallel writes itself: WordPress has *always* been the horizontal, extend-it-yourself platform — plugins are the "users go deep on the parts they need" pattern Theo's only now reinventing from scratch. Two cautions before you grab a sledgehammer: he punts entirely on security ("maybe a model allowed to do security stuff"), and the "the wall is far away" claim rides on toy apps, not production load. Still, the framing is worth a beat — if your job feels like it shrank to 15 hours, the answer might be to attempt the thing that used to take a team you couldn't afford to risk. Helpful follow-up: Theo promises an "ideas I wish someone would build" video next. ## ✅ Action Items #### DevRel - Developer advocacy: a talk/demo contrasting "vertical depth vs. horizontal breadth" strategy in the AI era, with a runnable example. - Education: workshop on architecting extensible platforms so users self-serve the depth you don't build. - Developer experience: publish a "go from local prototype to deployed in minutes" quickstart that removes the OAuth/DB/preview-env glue Theo complains about. - Developer marketing: clip the "don't automate old work — attempt new work" reframe as evergreen content. - Community management: host a builder jam around "boil the ocean" prototypes; surface where people actually hit the wall. - Internal/external/cross-project: collect data on real failure points of agent-built horizontal apps to ground the optimism. #### OSPO - Policy & Governance: guidance on AI-generated code provenance when agents "build everything" (e.g., copied design systems). - License Compliance: scan agent-generated dependencies in fast-built apps. - Security Management: address Theo's explicit security punt — define a baseline before "shitty apps" reach real users. - Software Inventory: SBOM strategy for code where "the code is the deployment instructions." - Developer Support: consultation hours on extensible-platform architecture. - Community Engagement: fund open-source "horizontal primitive" experiments (runtimes, bundlers). - Strategic Alignment: track "build-to-deploy time ratio" as an internal KPI. #### Community - Maintainers: roadmap clinic on whether to add breadth (more categories) vs. depth given AI build speed. - Contributors: "first issue" rotations on extensibility hooks that let users add unbuilt features. - Sponsors: Not applicable to this source. - Ecosystem: shared experiments on agent-built apps and their real scaling limits. #### WordPress - Core: note the strategic parallel — WordPress is already the extensible horizontal Theo is reinventing. - Core Performance: publish baselines so "boil the ocean" apps have a perf yardstick. - Core AI: align "apply/attempt, don't just automate" guidance; document extensibility as an AI advantage. - **Core Program Team:** coordinate a cross-team response to AI-accelerated build expectations. - Mobile: Not applicable to this source. - Playground: WordPress Playground is the closest analog to Theo's "spin up 10 apps in minutes" demo — promote it as exactly this kind of instant sandbox. - Community: WordCamp session on horizontal-vs-vertical strategy for plugin authors. - Training: learning path on prompt/agent-driven app scaffolding. - Marketing: amplify "WordPress is the original extensible platform" narrative. - Support: anticipate a wave of agent-built, security-thin sites. - Design: document ethics/limits of agents copying design systems. - Documentation: examples-first guide to extensibility hooks. - Photos / TV / Openverse: Not applicable to this source. - Polyglots: glossary for "boil the ocean," "horizontal vs. vertical play," "glue solution." - Accessibility: ensure agent-generated apps meet WCAG (see Accessibility Assessment). - Meta: Not applicable to this source. - CLI: scaffolding patterns for instant-deploy apps. - Hosting: onboarding-at-scale playbooks for a surge of tiny apps. - Tide / Themes / Plugins: Not applicable to this source. #### The WPCC - Programs: fellowship on open-source runtimes/bundlers as horizontal primitives. - Projects: documentation sprint on extensible-platform patterns. - Funding experiments: microgrants for "impossible-sounding" prototypes that test the wall. ### FAIR - Technical independence: self-hosted/extensible runtimes reduce SaaS-glue lock-in — document the pattern. - Policies and covenants: transparency on AI use and security posture in fast-built deliverables. - Productized governance artifacts: a "minimum security baseline for agent-built apps" charter. ## 🧪 Hypotheses - H1: AI-driven build speed makes "wide horizontal, shallow depth" products more commercially viable than they were pre-AI. - H2: Platforms architected for user-extensibility outperform fixed-feature platforms when build cost collapses (users supply the long-tail depth). - H3: The build-to-deploy time ratio has inverted (deploy now dominates), making deploy-glue abstraction the highest-leverage product opportunity. - H4: Agent-built "shitty apps" fail predictably at a scale/quality threshold ("the wall") that Theo's toy demos don't yet reach. - H5: Lowering the effort to publish small apps increases the *number* of apps shipped enough to create new aggregate value (long-tail elasticity), mirroring the cloud's effect. - H6: Security and reliability, not breadth, become the binding constraint for horizontal all-in-one platforms. ### 📊 Methodology - H1/H2: comparative case study of horizontal vs. vertical products built with/without agents, tracking adoption, retention, and per-feature usage. - H3: instrument real projects to measure build-time vs. deploy-time before/after agent adoption. - H4/H6: load- and security-test agent-built apps (LakeBed-style) to locate the failure threshold ("the wall") empirically. - H5: longitudinal count of small apps published per developer before/after low-friction deploy tooling; aggregate-value proxy metrics. ### ❓ Questions - Where exactly is "the wall" — at what user count, data volume, or compliance requirement does a "shitty horizontal" app break? - Does punting security to "a model allowed to do security stuff" hold up, or is it the first wall? - Is depth *really* the user's problem, or does offloading it just relocate the failure (cf. the DB-binary file-storage hack)? - How is this different from WordPress/Salesforce's existing extensibility — is Theo reinventing a solved pattern from scratch? - Does the optimism survive a real paying customer with a regulated workload? ### 🔮 Future Research - Empirical mapping of failure thresholds for agent-built horizontal apps across load, data, and compliance dimensions. - Comparative study: reinvent-the-stack (LakeBed) vs. extend-an-existing-platform (WordPress) for breadth strategies. - The economics of long-tail app proliferation — does cheaper publishing create net new value or just noise? - Security posture of agent-generated full-stack apps, and viable automated-security guardrails. ### 💡 Implications - **Practice:** Highest leverage may have shifted from writing features to abstracting deploy/integration glue and designing for user-extensibility. - **Policy:** Provenance, licensing, and a security baseline for agent-built code become necessary, not optional. - **Security:** Theo's explicit deferral signals an ecosystem-wide gap as build speed outruns safety review. - **Education:** Curricula pivot from "build the feature" to "imagine the system and architect for extension." - **Funding models:** Cheaper experimentation lowers the risk (and human cost) of big bets, potentially reshaping how ambitious projects get greenlit. ### 🧠 Learning Styles Assessment - Reading level estimate: spoken monologue transcript; ~Flesch–Kincaid Grade 8–10 (casual vocabulary, long run-on sentences, profanity, business jargon: "boil the ocean," "horizontal play," "glue solution"). Flesch Reading Ease ~60–70. #### 👀 Visual learners - Present: Theo references his on-screen diagrams (Salesforce feature spectrum, horizontal/vertical chart) and a live 10-app demo, though not visible in the transcript. - Improve: static versions of the range-vs-depth and Salesforce-spectrum diagrams; a before/after build-vs-deploy-time graphic. #### 🔊 Aural learners - Present: strong — it's a narrated video monologue. - Improve: chapter markers and a 3-minute audio recap. #### 🗣️ Verbal learners - Present: vivid analogies ("shitty cloud for shitty apps," "boil the ocean," "sledgehammer," cloud-as-groceries). - Improve: a glossary callout (horizontal vs. vertical, glue solution, boil the ocean). #### 🧩 Kinesthetic learners - Present: live demo of building 10 apps; implicit "go try it" call to action. - Improve: a hands-on lab — pick an "impossible" idea and prototype it with an agent; a checklist for finding your own "wall." #### 🧠 Logical learners - Present: clear causal chain (cheap code → wide range feasible → depth offloaded to users → new products viable) and the cloud analogy as inductive support. - Improve: a decision tree for horizontal vs. vertical; quantified elastic-demand math instead of vibes. #### 🧑‍🤝‍🧑 Social learners - Present: direct address to "y'all," community framing, promise of a crowd-sourced ideas video. - Improve: discussion prompts for builder communities; a shared "where did you hit the wall" thread. #### 🧘‍♀️ Solitary learners - Present: reflective "find the idea in the back of your mind" prompt. - Improve: journaling questions ("what did I avoid building because it was too risky?"). #### 🧠 Logical learners (duplicate guard) - Covered above; no separate content. #### 🌿 Naturalistic learners - Present: "boil the ocean" framing gestures at scale/ecosystem. - Improve: tie agent-built app proliferation to compute/sustainability tradeoffs (cost of "shitty apps" at scale). ### 📊 Accessibility Assessment #### Screen reader semantics - Present: YouTube provides title, description, and (auto) captions; transcript has timestamped structure. - Improve: human-reviewed captions; descriptive headings in the description; alt descriptions for the on-screen diagrams. #### Keyboard navigation - Present: YouTube player is keyboard-operable. - Improve: ensure any linked LakeBed/demo UIs have visible focus and logical tab order. #### Contrast and readability - Present: standard YouTube UI contrast. - Improve: verify on-screen diagram text meets 4.5:1; avoid low-contrast code-on-dark in demos. #### Text resizing and reflow - Present: captions scale; description reflows responsively. - Improve: confirm diagram text remains legible at 200% zoom. #### Media and captions - Present: auto-captions likely available (WCAG 1.2.2). - Improve: accurate human captions, a downloadable transcript, and audio description of the visual diagrams/demo (WCAG 1.2.5). #### Forms and interactions - Present: Not applicable — no forms in the video itself. - Improve: if LakeBed-built apps ship, ensure labeled inputs and accessible auth flows. #### Standards reference - Maps to WCAG 2.2 AA: 1.2.2 Captions, 1.2.5 Audio Description, 1.4.3 Contrast, 1.4.10 Reflow, 2.1.1 Keyboard, 2.4.6 Headings/labels. ### 🌍 DEIB Assessment #### Cultural breadth - Present: limited — single US dev-culture voice, Western tech-industry framing (AWS, Salesforce, Vercel). - Improve: examples from non-US/low-resource contexts where "cheap experimentation" matters most. #### Inclusive language - Present: casual, accessible; defines its own jargon via analogy. - Improve: frequent profanity and "shitty" framing may exclude some audiences; offer a plain, non-profane summary; define jargon inline. #### Neurodiversity support - Present: long unbroken monologue with few signposts. - Improve: add on-screen chapter headings, chunked summaries, and predictable section structure. #### Representation - Present: single senior male founder voice; no other perspectives. - Improve: include junior-dev or displaced-worker perspectives on the "fear" he opens with. #### Psychological safety - Present: names the fear directly ("they feel fear") and tries to reframe it constructively; acknowledges past layoffs honestly. - Improve: pair the "do more" optimism with concrete support for engineers who can't simply "go bigger"; avoid implying that fear is a failure to use the tools well. ### ✅ Logical Validity #### Strong reasoning - Analogical (cloud → AI): well-constructed and the backbone of the talk — the cloud genuinely lowered experimentation cost, lending inductive support to the AI claim. Located ~[00:02:41]–[00:05:22]. - Causal (cheap code → wide range feasible → depth offloaded): cleanly mechanized via the Salesforce/horizontal-vertical models ~[00:08:04]–[00:14:00]. - Honest falsification attempt: building LakeBed "to hit the wall" ~[00:21:41] is a genuine attempt to test, not just assert, the thesis. #### Fallacies - **Hasty generalization** — "I think you'll be surprised just how far off that wall is" ([00:22:46]–[00:23:18]), generalized from toy apps (to-do, poll, recipe) built in a demo. Fix: bound the claim to prototype-scale until production/load evidence exists. - **Survivorship bias / appeal to authority of his own success** — the whole "go bigger" exhortation is delivered by someone who already won (tRPC, UploadThing) and "can hire people to help me build" ([00:06:27]). Fix: separate advice that's repeatable from advantages contingent on his existing platform, capital, and audience. - **False dilemma** — "If you're not pushing yourself past what made sense before, you're not really using these tools for what they're capable of" ([00:23:18]). Fix: allow that automating existing work is also legitimate, lower-risk value, not a failure. - **Suppressed premise (security)** — "Maybe I'll have a model that's allowed to do security stuff so I can actually make sure it's secure before I go public" ([00:16:43]) quietly defers the hardest constraint while presenting the wall as far away. Fix: treat security/reliability as a candidate first wall, not an afterthought. #### Tone of voice - Contrarian, energetic, profane, founder-evangelist; self-aware ("it [__] with my brain"). Confessional about past layoffs and fear, which softens the hype. Mild self-promotion (his projects, his sponsor) balanced by genuine enthusiasm and an explicit "this isn't about specific tools" disclaimer. ### 🛡️ DARVO Analysis - Deny: Minimal — he doesn't deny AI's disruption; he affirms it ("a lot of that can be done in 15 hours") and reframes rather than minimizes. The security gap is deferred, not denied. - Attack: None directed at people — he gently critiques the industry for "not building big enough" and devs for only automating old work, but as exhortation, not personal attack. - Reverse victim/offender: None — no accuser/accused dynamic. If anything he positions engineers' fear as understandable, not as something to weaponize. - Overall: DARVO is largely **not applicable** to this source. The nearest tension is reframing AI-driven job anxiety as opportunity, but Theo names the fear openly and shares his own discomfort, which weighs against a defensive DARVO reading. ## 🎯 Conclusion - **Bottom line.** Theo's thesis: AI compressed the cost of building the way the cloud compressed the cost of scaling, so the rational response to "my work now takes 15 hours" is to attempt the bigger, formerly-uneconomical thing — a wide, "shitty horizontal" all-in-one where users extend the depth you skip. LakeBed is his proof-of-concept that "boiling the ocean" hasn't hit a wall yet. - **Next steps for readers.** (1) Identify one idea you avoided because it was too big/risky pre-AI. (2) Prototype it with agents and find where it actually breaks. (3) Architect for user-extensibility instead of building every feature. (4) Treat security and production load as the likely first wall — don't defer them the way the demo does. (5) Watch for Theo's follow-up "ideas I wish someone would build" video. ## 🔄 Refactor Appendix — It's time to go bigger > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults applied. Resonance filter on. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] AI lowers build cost the way the cloud lowered scaling cost > [!quote] ID:rw_pending > "we've been through this before and just because AI is this crazy thing changing how we build doesn't mean our jobs are going away" **Context & use**: - [00:04:50] The central analogy: cloud made experimentation cheap; AI does the same for building. - Reframes AI-displacement fear as a precedent-backed opportunity. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H2] AI makes horizontal breadth viable; depth becomes the user's problem > [!quote] ID:rw_pending > "building a really good vertical isn't the only path to success anymore. And instead, building a shitty horizontal play" **Context & use**: - [00:13:28]–[00:19:54] Architect so users extend unbuilt parts; range, not depth, is now achievable. - Counters 20 years of "pick one vertical and go deep" startup doctrine. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H3] Build time collapsed but deploy/integration glue didn't > [!quote] ID:rw_pending > "I could build the same app in 30 minutes, but deploying still takes just as long. This pissed me off." **Context & use**: - [00:16:11] The build-to-deploy ratio inverted; integration glue is now the bottleneck. - Motivates reinventing the whole stack instead of building more glue. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H4] Don't automate old work; attempt work that was previously impossible > [!quote] ID:rw_pending > "Developers are still trying to use these tools to automate the existing work they did before. They're not realizing that it enables different types of work." **Context & use**: - [00:22:13] The core exhortation; "push until you hit the wall." - Cross-ref: relates to loop-engineering's "agents doing more, not just faster" framing. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] When build cost collapses, breadth beats depth **Claim** (one sentence, Courtney's voice): Once the cost of building any single feature approaches zero, the competitive advantage shifts from going deep in one vertical to covering the widest possible range and letting users supply the depth they need. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds where the platform can be architected for user-extensibility and where "good enough" breadth has real utility. Breaks where depth/quality or regulated reliability is the binding requirement, or where security can't be deferred. **Links**: - [[Horizontal vs vertical strategy]] — because extends - [[WordPress as extensible platform]] — because applies-in the existing-precedent case - [[Vertical SaaS moats]] — because contrasts on where depth still wins <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Note the WordPress/Playground parallel — Theo is reinventing the "users go deep via plugins" pattern from scratch; worth an article. — https://www.youtube.com/watch?v=WBT-z_-OPhw #fleeting #inbox - [F2] Open question: where is "the wall" for agent-built horizontal apps — load, data volume, or security? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a short note connecting "boil the ocean" to WordPress's existing extensibility model — #things - [ ] Add "breadth beats depth when build cost collapses" to the AI-development resource — #things <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/It's Time to Go Bigger.md|It's Time to Go Bigger by Theo - t3.gg]] ## Highlights - trying to say here is that we've been through this before and just because AI is this crazy thing changing how we build doesn't mean our jobs are going away or that this field is going to die. I argue that it's kind of the opposite. The same way something like AWS made us go from building bespoke internal software for big companies to building new services and solutions. Everything from Slack to Salesforce. Yeah, they acquired each other. It is what it is. You get the idea though. There's so much software that just didn't make sense when you couldn't provision it at scale trivially. And more importantly, you ([View Highlight](https://read.readwise.io/read/01kvkrky4qbxffsswsz5pye7kk)) - Note: H1 — the cloud→AI analogy: like AWS enabled a wave of new software, AI won't kill dev jobs — it enables work that didn't make sense before. - Tags: atom/literature/h1, ai-and-work - less than a tenth of my total time, so I didn't give a [ \_\_ ] Now I do because I could build the same app in 30 minutes, but deploying still takes just as long. This pissed me off. O was annoying me enough that even with awesome solutions like work OS and clerk, I still had to spend too much time in dashboards, too much time attaching the pieces when all I wanted was a simple Google sign-in button. I built Shu to effectively be a Google O broker to abstract that layer so I don't have to build it into every single service or set up another app in another provider to do it. There is no dashboard and shoe for you as a ([View Highlight](https://read.readwise.io/read/01kvkrm77bmc60gyednw8ewveh)) - Note: H3 — the bottleneck inverted: "build the same app in 30 minutes, but deploying takes just as long" — integration/auth glue is now the binding constraint. - Tags: atom/literature/h3 - instructions for the deployment. Still very early in the development of Lakebed. I have some agents in the background making improvements as we speak. I am hoping to have this ship soon. I'm showing this because I want you guys to start thinking the way I am now. I want to encourage this boil the ocean mindset. this idea that we can finally go horizontal with the things we're building. That building a really good vertical isn't the only path to success anymore. And instead, building a shitty horizontal play, something that is bad but functional in every category someone might need. Building a shitty ([View Highlight](https://read.readwise.io/read/01kvkrm2m1esvbsnhgbcz7t0mk)) - Note: H2 + Permanent: when per-feature build cost → zero, a "shitty horizontal play" (wide but shallow) becomes viable, inverting 20 years of go-deep-in-one-vertical doctrine. - Tags: atom/literature/h2, atom/zettel/z1 - doing this now. And that's also why I'm making this video. I don't think we're building big enough right now as an industry. Developers are still trying to use these tools to automate the existing work they did before. They're not realizing that it enables different types of work. And that's where this stuff starts to get really, really fun. And that's why I'm even more excited for the follow-up video I'm going to do where I showcase some of the ideas that I wish someone else would build because I don't have the time to do it. Going big like this takes a lot of your energy and focus, and it's so fun, but I can only do it on one thing at a time. And ([View Highlight](https://read.readwise.io/read/01kvkrmbb9wa2zn7e9nac9f24w)) - Note: H4 — the call to action: developers automate the *old* work instead of realizing AI enables *different* work (echoes the loop-engineering "do more, not just faster" cluster). - Tags: atom/literature/h4, loop-engineering