WhoBuilt

Fun Is Velocity

Aug 10, 2026· 42 min· 28K views·Watch on YouTube

Speaker

Peter Steinberger, founder of OpenClaw, describes building the open-source AI agent and the lessons he learned in a Y Combinator talk and Q&A.

An idea built from frustration

Steinberger started OpenClaw after getting annoyed that he could not check on a coding agent from his phone. A WhatsApp relay made that possible, and its concise, proactive replies led friends, including nontechnical ones, to ask to use it. He saw their strong reactions as a sign that the product met a real need.

Going viral brought new pressures

Steinberger opened a Discord room where people could interact with the agent as he built it. After he thought he had stopped it, its launch daemon restarted; by morning, it had answered around 800 messages, and the project went viral. He says the attention, security reports, and growing feature set nearly overwhelmed him; at one point, he counted about 9,500 configuration options.

Dependencies and focus shaped the project

Steinberger says OpenClaw was too dependent on Anthropic’s Opus model, so the company’s decision to disable subscription access with about 24 hours’ notice left little time to adapt. He also describes spending too much time on security, features, press, and organization while competing projects marketed a simpler story. Weekly downloads fell to about 835,000 in May, then reached 4.7 million in June, showing how quickly attention can shift.

Fun restored momentum

By February, OpenClaw felt like a responsibility, and Steinberger had stopped using his own product. After bringing on help and forming a nonprofit, he began enjoying the work again around May. He says the product improved during weeks he enjoyed building, while weeks without that energy tended to produce more configuration options.

Build for yourself and keep the project focused

Steinberger wants OpenClaw to make AI more approachable through open-source software, education, and an ecosystem that works across models and devices. In the Q&A, he says user one should be the builder, code review should reflect risk, and open-source maintainers should communicate a clear vision. He also points to reliability, compute management, and affordable Mac test environments as unresolved needs.

Takeaways

  • Start with a problem that annoys you, and build something you want to use.
  • Let real users’ reactions guide whether a prototype solves a meaningful problem.
  • Treat key suppliers’ business models as part of your own business risk.
  • Write down a project vision and weigh the maintenance cost before merging features.
  • Match review effort to risk, and use your judgment when changes take longer than expected.

Mentioned in this talk

Search inside this talk

What was claimed 12

Related talks