Peter Steinberger: "Fun Is Velocity"

Why does it matter? Because 'building for everyone' is how you end up with 9,500 config options and a product you've stopped using.

Peter Steinberger built OpenClaw on a rainy afternoon out of personal annoyance, watched it go viral overnight, and then spent the next six months nearly deleting all of it — not because a competitor beat him, but because trying to serve everyone destroyed the thing that made it great. The warning signs were invisible to the outside world and obvious in retrospect: he'd stopped using his own product.

• Fun is a diagnostic metric, not a personality quirk — when it disappears, the config options multiply and product quality follows
• 9,500 configuration permutations is the measurable cost of never saying no to a pull request
• Anthropic gave roughly 24 hours' notice before disabling subscriptions and nearly ended the project
• Non-technical friends getting angry they can't have your product yet is a stronger PMF signal than any analytics dashboard

Fun is velocity — when the joy of building leaves, product quality follows it out the door

The weeks the product got better were the weeks the builder was having fun. The weeks it didn't, the team shipped config options. Steinberger drops that observation almost in passing, but it's the spine of the whole talk: "Fun is velocity. The weeks I enjoyed building the product got visibly better. The weeks I didn't, we shared config options."

The pattern is more precise than it sounds. Configuration sprawl isn't a product philosophy — it's what defensive building looks like when the builder has stopped using the thing with genuine curiosity. When you're having fun, you know immediately what feels wrong. When you're not, you hedge with options.

By February, something had shifted. The inbox had exploded, security researchers were calling in the middle of the night, lawyers needed hours, and OpenAI had its own gravitational pull. "Somewhere in that time, I stopped making." He'd built something for himself, then almost imperceptibly started building for an imagined composite of 18,000 contributors. "I started to make a product I love and I worked on making something for everyone." The pivot sounds reasonable. The output made the problem legible.

Fun is a leading indicator. When it drops, something structural has broken — the feedback loop between builder and product, the daily use that catches problems before users do. "It's hard to compete with someone who's just there having fun." The correct response to losing it isn't to push through. It's to stop, find the root cause, and fix it before shipping anything else.

9,500 configuration permutations is what 'ship for everyone' looks like at the end

Every feature you ship is permanent. At their peak, OpenClaw had 9,500 configuration permutations — a combinatorial testing problem that made meaningful changes almost impossible without breaking something for someone, somewhere.

"Features are the fun part. A new feature is just a prompt away. The real cost comes after." Every feature shipped with a configuration option, because the team didn't want to break existing setups. That sounds like responsible stewardship. Compounded across hundreds of contributors and months of additions, it became an untestable maze. "You can write all the tests you want. It is impossible to cover all of these and not break things from time to time."

There's a social dynamic in open source that made this worse: contributors worked for free, put real effort in, and it felt wrong to reject features on philosophical grounds. "Who am I to tell them what to do?" The community rewarded addition. Nobody celebrated subtraction.

Steinberger now writes a vision.md for any new open source project — not just what it is, but what it will never become. He wishes he'd applied a simpler rule earlier: never add a configuration option without retiring one. The marginal cost of each addition is borne by every future engineer who touches the codebase, multiplied across every combination of settings any user might be running. The feature felt free at the time. The debt compound silently.

Anthropic gave 24 hours' notice and nearly ended the project — your dependency's business model is your business model

OpenClaw was built on Codex and GPT, but the harness was tightly optimized for Opus. That optimization made the product excellent. Then Anthropic pinged Steinberger with roughly 24 hours' notice that they were disabling subscriptions for everyone.

"Your dependencies business model is your business model." The project supported open weight models, but they weren't ready — "the early open weight models simply lacked character." There wasn't time to change course. Downloads bottomed out at around 835,000 weekly in May. After being declared dead in June, the project peaked at 4.7 million weekly downloads, the highest ever. Both numbers are simultaneously true. But the vulnerability that caused the trough was structural, not bad luck.

The problem wasn't building on a vendor's API — almost every meaningful product does. The problem was optimizing so deeply for that vendor that diversification became expensive to retrofit under crisis conditions. Model-agnostic architecture needs to be a first-class constraint from day one, not something you bolt on after a near-death experience.

"That's all fixed now. Open weight models are actually good. I learned a lot about harness engineering. But in many ways, people move forward. People move on." Audit your single-vendor dependencies before you're forced to.

Everything you build can be forked. Your name cannot.

The big labs didn't call because OpenClaw had the best TypeScript in the world. They called because Peter Steinberger had become a noun. "I kind of made Claw a noun. Kapati dropped the open. Satya says enterprise grade claws in Microsoft's keynote." There are 33,000 repositories on GitHub with "Claw" in the name. The project went through several naming crises and the brand survived all of them. Code forks constantly. The person behind it doesn't.

Steinberger had an audience before OpenClaw shipped. Years of building B2B software in public, a following on Twitter accumulated long before the viral moment — all of that was infrastructure that amplified the launch when it came. When Sam and Mark and others called, it wasn't the codebase that warranted those conversations. It was the name.

"Everything you can build can be forked or cloned. But your name cannot. So your personal brand is way more important than any single product that you ever will. Start working on that before you need it."

Before is doing the work in that sentence. Not as a launch strategy, not as a content calendar. As the infrastructure that makes every future product launch cheaper — distribution already built, credibility already priced in, amplification already assembled.

The builder who stopped using his own product didn't notice the quality collapsing until it was already gone

"User number one should be you. And my users two to 20 were friends." Steinberger stayed up all night watching early Discord users interact with OpenClaw before he'd announced it publicly. He created WhatsApp group chats just to observe reactions. He iterated based on what he personally found broken or missing.

Then the project scaled. Security researchers called in the middle of the night. The press needed handling. The nonprofit needed lawyers. OpenAI had its own demands. Daily use quietly stopped being something Steinberger did. "Worst of all, I stopped using my own product."

The degradation wasn't dramatic. No single decision broke anything. What broke was the feedback loop that had kept quality honest: the builder's personal daily irritation at things that were slightly wrong. User research and bug reports are lagging indicators — they tell you what already broke. The founder using the product every day is the only leading one, catching the slow drift before users encounter it.

You cannot outsource this signal. No process compensates for its absence. If organizational demands have crowded out your own daily use of what you're building, that's not a scheduling problem. It's a product health crisis developing in slow motion.

The PMF signal is non-technical friends getting angry they can't have it yet

Before OpenClaw existed, Steinberger spent weeks trying to explain on Twitter why his WhatsApp relay felt like the future. Smart people who understood the space read his posts and scrolled past. So he changed methods: group chats, live demos, handing the product to people and watching their faces.

"Every time I got a strong emotional reaction. Some people were amazed. Some people were scared or freaked out even. But each time, there was a strong emotion."

Then the tell: "Especially to my non-technical friends. I told them, no, this is not yet for you. And they got mad. So if that's not an indicator to have product market fit, I don't know what is."

Technical users rationalize their reactions — they say "interesting" even when they have no plans to use something. Non-technical users who get frustrated at being turned away can't fake that. Desire running into friction doesn't perform. Mild interest from people who understand the space is noise. Genuine irritation from people who don't is signal.

Put the thing in front of five to ten non-technical people. Measure intensity, not valence. Scared counts. Amazed counts. Polite does not.

The '20% malicious skills' claim stuck. The real number — 0.3% — never caught up.

The press reported that 20% of OpenClaw's skills were malicious. Steinberger's team scanned all 67,000, wrote a paper, and published the real number: 0.3%. It didn't matter. "A correction never travels as far as a scare."

The researchers themselves were mostly filing unverified reports. "Most of them really sent reports that their agent produced without actually even testing it." The incentive structure of responsible disclosure rewards filing, not verifying. What followed was months of security hardening — sandboxing, allow lists, a web protocol with permissions built in — that consumed the focus that should have gone to product. Almost none of it registered with users. "Most of the users didn't care shit about that. Sure, they liked the abstract term of security. But in all practical terms, they updated. I broke something they're dependent on. I made things slower."

"I would be less stressed out about security researchers... I lost a few months and got a few gray hairs to learn." Define your security posture proactively and in public — what you guarantee and what falls outside your boundary. Waiting to respond to filed reports cedes the narrative to whoever files first.

Annoyance is a product roadmap — every major thing Steinberger built started as something that personally irritated him

"My source of inspiration is usually being annoyed." He opened with it and closed with it. The WhatsApp relay came from walking back from the kitchen and finding his coding agent had stopped for something stupid. OpenClaw came from failing, week after week, to explain why the relay felt magical — that failure was annoying enough to demand a solution. "These days I get annoyed when I have to use software where I can't just send a prompt to my agent to change it." That's the next product.

Annoyance-driven building has structural advantages. There's an immediate user: you. There's a concrete pain threshold — the thing irritated you enough to build rather than tolerate. There's a natural success condition: does using the product make the annoyance stop? And there's a distribution shortcut: people with similar workflows share similar friction points.

"Fix the things that annoy you. It might just become the next big thing." The key is actually cataloging the friction, because most people don't bother. The ones worth pursuing are the irritations that persist across weeks despite half-solutions — the ones you keep working around instead of fixing.

The signal that connects all of it: a builder who uses their own product every day, annoyed, and still having fun

What runs through every lesson here is a model for what makes software excellent when anyone can clone your product over a weekend: the builder's daily emotional engagement with the thing. Not product reviews, not contributor consensus, not security audits — the founder's personal irritation, compulsive daily use, and the specific joy that comes from fixing something that was broken.

When those conditions hold, quality follows almost automatically. When any one breaks — when the builder stops using the product, when annoyance gets optimized away, when fun disappears into organizational drag — no process fills the gap.

The next great AI product will probably start with someone standing in a kitchen, annoyed.

---

Topics: open source, product development, founder psychology, AI tools, burnout, product-market fit, dependency risk, personal brand, feature creep, agentic software