Million Users, Million Forks

OpenClaw, an AI-powered software that writes its own code to perform tasks, enables a "one fork per user" model where each user can customize their own version of the application. The approach combines copy-on-write storage and scale-to-zero compute, using technologies like Neon for database branching and Cloudflare's Durable Objects for isolated, idle-cost-free compute. While most users will not customize the software, a small fraction will create forks that can be shared through a marketplace, making the product a malleable base with installable extensions rather than requiring every user to build their own.

Million users, million forks The most interesting thing about OpenClaw isn't that it books your flights. It's that it writes its own code: when it can't do something, it writes a new skill for itself and then does it. People started calling it "Claude with hands." The loop — talk to the software, the software rewrites itself — is what got me hooked onto it. However, OpenClaw is a blank canvas. It does nothing until you point it somewhere. The version I can't stop thinking about is where the software already works, where the chat box is just there to let you bend it. For example, a personal finance planner that tracks your taxes, but then gives every user a text box that says change anything you want to make it work better for yourself. The first thought you might have: you cannot host a separate codebase for every user. And if you're picturing a million literal repos, sure that'll be impractical. But that's not the solution I'm thinking of. "One fork per user" is two solved problems: copy-on-write storage and scale-to-zero compute put together. The storage was never the problem Code is text, and a fork is just a diff off a shared base — Git has done this for a while now. The more interesting part is forking the database. A real fork of a financial planner adds new database tables, tweaks a schema, keeps its own state, and a full private database per user is the thing that doesn't scale — unless your database also branches. This is exactly what Neon https://neon.com/ does to Postgres: fork the database like you fork code, pay only for the delta. Databricks bought them for about a billion dollars, specifically to serve AI agents. Compute is the same trick from the other side. The only fork costing you money is the one running right now — your user checks their budget once in a while, not continuously. Cloudflare's Durable Objects https://developers.cloudflare.com/durable-objects/ read like they were built for this: one per user, with their own isolated database, no charge while idle. Val Town https://www.val.town/ has shipped a version for years, and made the sharper choice — it spawns a process per request and interprets the code instead of building it. Normal SaaS builds once and serves a million people. A per-user-fork product runs a tiny CI job every time someone says "move the chart up," and a financial app has to also answer did this change break the math. The solution is easy: don't compile. Interpret, hot-reload, keep edits inside well-defined extension points so verifying a change is cheap and the blast radius is small. The hard problem that's left, then, is making the change cheap. Who forks You might wonder: who even wants to edit their own financial planning software? It's a fair thought, and yes, the answer is almost nobody. Most people just want the thing to work and move on. But the people who will fork aren't distributed evenly. It's a power law. One user in a hundred rebuilds the budgeting view into the exact tool they wished existed. The other ninety-nine don't want to build it — they want to install the one that person built. So the product really isn't a "fork per user". It looks like a malleable base plus a marketplace of forks on top of it. OpenClaw already worked out its way into this — its skills are shareable, installable, published to a hub, and yes you can write one, but it's more likely that someone already wrote the one you needed.