A letter to tech CEOs
TL;DR
Theo’s thesis is blunt: closed-source may become the riskier bet — despite real downsides like cloning, self-hosting, and security exposure, he says he’s now advising portfolio companies to go “as all-in on open source as they possibly can” because AI changes the competitive math.
Incumbents like Salesforce win by hoarding edge-case features, but AI weakens that moat — Theo’s example is a CRM with 1,000 features where any one customer uses 50, and one missing bespoke feature can block a migration; his argument is that future products should let customers build their weird 1% features themselves instead of waiting on vendor roadmaps.
Plugins aren’t the answer; code ownership is — he contrasts painful plugin systems with Vercel’s model, where users can write their own code around a narrow platform, arguing that the winning products will be modular building blocks users and agents can directly modify.
T3 Code gave him the proof point: roughly 1,500 forks from about 16,000 weekly users — that means around one-tenth of weekly users forked the product, and examples like Emanuel’s heavily customized “DP code” convinced Theo that customers don’t just want software anymore, they want a skeleton they can reshape.
Mitchell Hashimoto’s ‘building block economy’ reinforces the same shift — Theo cites Ghostty reaching 1 million daily users in 18 months while Libghostty surpassed that in just 2 months, using it as evidence that reusable components now spread faster than polished mainline apps.
His big product idea is ‘patch.md’: software that remembers customization intent, not just code diffs — instead of fragile patch-package hacks, Theo imagines apps with a Customize button, agent-assisted updates, and a text file describing every local modification so forks can survive upstream changes.
The Breakdown
Why he’s losing faith in closed source
Theo opens from a place of frustration: AI has made companies more willing to ship low-quality software, and he’s tired of being trapped inside products he can’t fix or tailor himself. Even though he fully acknowledges the obvious risks of open source — easier cloning, self-hosting, and more exposed security surfaces — he says the bigger risk may now be staying closed.
The real downsides, with T3 Chat as the painful example
He doesn’t hand-wave the dangers away. He points to Cal.com dealing with a flood of security reports and attempted exploits, and says the reason T3 Chat still isn’t open source is brutally practical: it’s a 2.5-person team, and one security issue could cost them millions in seconds. T3 Code is easier because it runs with the user’s own subscription and machine, not Theo’s infrastructure.
Why giants like Salesforce are so hard to kill
This is where he switches into business-mode Theo. His Salesforce example is the core frame: imagine 1,000 features, with any customer only using 50, but one random bespoke feature being enough to block a migration even if a new competitor nails the other 49. That’s how big SaaS companies keep customers trapped — not because every feature is great, but because they’ve accumulated years of weird little edge-case functionality no startup can afford to replicate.
Vercel works because users can finish the missing parts themselves
Theo says plugin systems sound like the answer until you’ve actually built one and suffered through the support nightmare. What worked better, in his view, is Vercel: not because it does everything AWS does, but because it does a narrow thing well and lets you write code around the rest — use Cloudflare, Supabase, Convex, whatever. His distinction is important: not plugins, but code you own.
The T3 Code fork explosion broke his brain
The numbers are what changed his thinking. T3 Code has seen about 42,000 installs, around 16,000 weekly users, nearly 9,000 GitHub stars, and about 1,500 forks — an absurd level of customization pressure for a new dev tool. He’s especially energized by examples like Emanuel, who turned his fork into “DP code,” added split chat, queuing, plugins, terminal-heavy workflows, and features Theo now wants to bring back upstream.
AI makes customization normal, not niche
That fork behavior matters more now because AI lowers the cost of making changes dramatically. Theo imagines a future where customers don’t just self-host a tool like PostHog — which he doesn’t want to do because he has zero interest in managing a ClickHouse cluster — but can customize the product layer while still paying for the hosted backend. That’s the commercial sweet spot he keeps circling: your app is theirs to shape, but your infra still powers it.
Mitchell Hashimoto’s ‘building block economy’ gave him backup
Theo spends a big chunk reading and reacting to Mitchell Hashimoto’s essay because it validates his gut feeling. The key line: AI is okay at building from scratch, but really good at gluing together high-quality, well-documented components — which means reusable building blocks now spread faster than full products. Theo connects that directly to developer tooling trends, npm-installable systems, and why agents tend to prefer open, modular tools over closed ones.
His big idea: patch.md and self-forking software
The final stretch is the most speculative and most memorable. Theo proposes “patch.md,” a file that records the intent behind customizations in plain language so an app could survive upstream updates, use an agent to resolve conflicts, and reapply features if needed. His bigger vision is software that is self-forking, self-customizing, and self-healing — and his closing pitch to founders is simple: if average users can now prompt their features into existence, the platforms that let them do that will win.