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 some code for itself to do it. People started calling it "Claude with hands." The loop — talk to the software, the software rewrites itself — is what got me hooked on it.
However, OpenClaw starts with a clean slate. You have to come up with your use cases. The version I can't stop thinking about starts with a useful piece of software that already works, then gives you a chat box to shape it to your needs. Imagine a personal finance planner that tracks your taxes and gives every user a text box that says change anything you want.
The first thought you might have: you cannot host a separate codebase for every user. And if you're picturing a million literal repositories, servers, and databases, that would be impractical. But that's not the solution I'm thinking of. "One fork per user" can be built from two established primitives: copy-on-write storage and scale-to-zero compute.
Copy-on-write storage
Code is text, and a code 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. Going back to our example, a real fork of a financial planner might add tables, change a schema, and keep its own state. A full physical copy of the database for every user would not scale well, but the database can also branch. This is what Neon does for Postgres: fork the database as you fork code, then pay for the delta.
Scale-to-zero compute
Compute costs accrue mainly while a fork is running — your user checks their budget once in a while, not all the time. Cloudflare's Durable Objects point in this direction: isolate state per user and avoid paying for idle compute. Val Town demonstrates another piece by spawning a process per request and interpreting the code instead of compiling it.
Zooming out, normal SaaS apps are built once and serve a million people. A per-user-fork product would run a tiny validation job every time someone says "add a way to select cost basis." A financial app also has to answer: did this change break the math? That likely requires keeping edits inside well-defined extension points so that verification is cheap and the blast radius is small. OpenClaw's skills point in this direction.
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 a piece of software to work and move on. But then, there are people (like us) who will fork. 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 has already found its way into this model: its skills are shareable and published to a hub. Yes, you can write one, but it's more likely that someone already wrote the one you need.
The result is less like a million isolated codebases than a tree: a malleable base, a smaller number of useful forks, and many users installing and adapting them.