Cloudflare and Anthropic Are Buying the Whole JavaScript Toolchain. Pieter Levels Still Runs ~$3M a Year on PHP, jQuery, and SQLite. Pick a Side.
Cloudflare and Anthropic Are Buying the Whole JavaScript Toolchain. Pieter Levels Still Runs ~$3M a Year on PHP, jQuery, and SQLite. Pick a Side.
In January, Cloudflare acquired Astro. On June 4, it acquired VoidZero, the company behind Vite, Rolldown, Oxc, and Vitest. Earlier this month, Anthropic acquired Bun. Add it up: a big chunk of what a 2026 developer thinks of as "modern, neutral JavaScript tooling" (the build tool, the bundler, the test runner, one of the runtimes, a popular meta-framework) now sits inside two companies whose actual business is selling you compute and AI.
Meanwhile, Pieter Levels, probably the most-cited solo operator alive, runs a portfolio reportedly pulling around $3 million a year on vanilla PHP, jQuery, and SQLite. No build step worth mentioning. No framework that could get acquired out from under him. He's said he hasn't written much code in months; he points AI assistants at a stack that's barely changed since 2010 and ships.
Those two facts, side by side, are the most useful thing you'll read about your stack this year.
"Neutral" tooling now has a landlord
The pitch for the modern JS toolchain was always neutrality. Vite doesn't care where you deploy. Astro is framework-agnostic. Bun is just a faster runtime. You adopt them because they're good, not because you're picking a vendor.
That story is over. When Cloudflare owns your bundler and your meta-framework, the roadmap optimizes for Cloudflare's platform. That's not a conspiracy, it's just what owning something means. To Cloudflare's credit, Vite, Rolldown, Oxc, and Vitest stayed open source with a $1M community fund, and that genuinely matters. But the people setting priorities now have a deploy target to sell, and the gravitational pull of that shows up over years, not in the first press release. Same with Anthropic and Bun: a runtime owned by a model company will, over time, get very good at running agents and AI workloads, because that's what its owner needs it to be good at.
None of this makes the tools bad. It makes them not neutral. And "the foundation of my product is owned by a company whose interests aren't mine" is a different risk than the one you signed up for.
The cost of living on the frontier of tooling
Here's what chasing the newest toolchain actually costs a one-person business, and it's rarely counted.
Every migration is time you didn't spend on the product. Every framework that changes hands is a roadmap you now have to track. Every "we're deprecating the old API" is a forced upgrade on someone else's schedule. Every acquisition is a new set of incentives quietly bending the thing you depend on. For a funded team with a platform engineer, that's a manageable tax. For a solo operator, it's pure overhead: the work that feels like progress because you're typing, but moves no metric your customers care about.
I've paid this tax. I've migrated a side project between build tools for performance gains the users never noticed, and rewritten a deploy pipeline because a framework changed its recommended pattern. Net effect on revenue: zero. Net effect on the weekend: gone.
Boring stack, AI on top
The Levels pattern isn't "PHP is better than Astro." It's a philosophy: pick primitives so boring and so widely-owned that no acquisition can disrupt them, and put your novelty budget into the product and into AI doing the labor, not into the plumbing.
PHP, SQLite, server-rendered HTML, a sprinkle of JavaScript: none of it can be acquired out from under you, because nobody owns it. SQLite isn't a startup. PHP doesn't have a corporate roadmap that bends toward selling you hosting. These tools were stable a decade ago and they'll be stable a decade from now, which means the time you'd spend tracking toolchain drama goes back into shipping. And the part that's genuinely new in 2026, AI writing and maintaining a lot of that boring code, works better on boring stacks, because there's a mountain of training data and the patterns don't shift under the model's feet every six months.
That's the actual edge. Not the newest runtime. A stack so dull that AI handles most of the labor and no corporate parent can yank the rug.
What I'd actually do
If you're starting something new and your goal is a durable one-person business, bias hard toward boring: a mainstream language with a decade of stability, SQLite or plain Postgres, server-rendered pages, and the minimum JavaScript that does the job. Let AI assistants carry the implementation. Spend your scarce attention on the product and the customers.
If you're already on the modern toolchain and it's working, don't rage-migrate; that would just be the same tax in the other direction. But do notice who owns each piece now, and stop adopting new tooling reflexively just because it's faster or trendier. "Faster build" is not a customer benefit. Ask of every tooling change: does this move a number my users feel? If not, it's a hobby, and you should be honest that you're doing it for fun, not for the business.
Where this take is weakest
In fairness: Levels is a survivor, and survivorship bias is real. For every indie hacker thriving on vanilla PHP there are plenty who never shipped at all, and the stack didn't decide it. The modern toolchain also exists for good reasons: type safety, component reuse, real interactivity that's genuinely painful to hand-roll. If you're building something heavily interactive, "just use jQuery" is nostalgia, not advice, and a modern framework will save you more time than it costs. And Cloudflare keeping VoidZero open source with a funded community is a meaningfully better outcome than a closed acquisition; open source under a corporate parent is not the same as a rug-pull.
But the core point survives all of that. For a solo operator optimizing for durability and shipping speed, novelty in your foundation is a cost, not a feature, and AI changes the math toward boring, because it does the boring work for you. Pick the stack nobody can sell. Spend the saved hours on the thing customers actually pay for.
Author
Lukas
@lukcombinator