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 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 read like they were built for this: one per user, with their own isolated database, no charge while idle. 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.