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 onto it.
However, OpenClaw starts with a clean state. You have to come up with your use cases. The version I can't stop thinking about is where a useful piece of software already works, and the chat box is there to let you shape it to your needs. 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, servers, and databases, 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.
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 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 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.)
Scale-to-zero compute
The only fork costing you money is the one running right now — your user checks their budget once in a while, not all the time. Cloudflare's Durable Objects read like they were built for this: one per user, with their own isolated database, no charge while idle. Val Town spawns a process per request and interprets the code instead of compiling it.
Zooming out, normal SaaS apps build once and serves a million people. A per-user-fork product runs a tiny CI job every time someone says "add a way to select cost basis" and a financial app has to also answer did this change break the math. The solution probably involved keeping edits inside well-defined extension points so verifying a change is cheap and the blast radius is small. This is something OpenClaw did really well.
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 already worked out its way into this — its skills are shareable, published to a hub, and yes you can write one, but it's more likely that someone already wrote the one you needed.