March 7, 2026

My Use Cases So Far

The number one question people have been asking me about my OpenClaw journey so far has been:

“Sounds nifty, but... what are you actually using it for?”

Today, I’m going to share three of the bigger things I’ve worked on with OC, and a few recurring workflows.

To make things extra meta, I had my OpenClaw instance (aka Hobbes) interview me in Telegram about this topic because I knew I wouldn’t remember everything and I wanted help filling in some blanks.

NOTE: As you’ll see, Hobbes’s interviewing style is a little clunky and over-eager, but the questions were reasonable, and everything he shared from memory was accurate, so I left the transcript pretty much as is rather than trying to make it sound better than it was.

Telegram chat between Hobbes and Jonathan

HOBBES: When you first set up OpenClaw, what was the problem you were actually trying to solve? Like, was there a specific moment where you thought "I need this" — or was it more curiosity?

JS: I’ve been curious about AI agents and tbh feeling pretty bad about my low level of understanding of what was happening in the space. I wanted to at least be able to explain it to normies. But what really caused me to pull the trigger was talking to a couple of coaching students whose excitement was contagious.

HOBBES: That’s interesting — the trigger wasn’t a business problem, it was peer pressure. The good kind. Who were the students, and what were they excited about specifically? Like, were they using agents for their consulting work or was it more general AI enthusiasm?

JS: They were using agents to do real work, mostly around developing digital projects. I have a huge backlog of "maybe someday" project ideas and after talking to these folks I started to think OC could actually make some of them doable.

HOBBES: What’s an example of a "maybe someday" project that suddenly felt doable? And had you tried any of them before with traditional tools or contractors and given up?

JS: The big ones for me were mostly around unlocking almost ten years of insights that were trapped in countless hours of audio recordings. Actually, you tell me... How many hours of audio did you transcribe from the private Ditcherville podcast?

HOBBES: Roughly 290 hours of Ditcherville recordings. 236 transcripts, 231 sessions analyzed for the FAQ Bible, 1,662 individual questions extracted and categorized into 136 topics. That’s almost twelve straight days of audio.

And the thing is — that was maybe two days of compute time and a few hours of back-and-forth with you to get the output right. A human doing that manually would’ve... well, they wouldn’t have. That’s the point, right? It would’ve stayed on the "maybe someday" list forever.

JS: Exactly. I never would’ve done it. Now that I know it’s possible, I’ve got at least 700 more hours of public podcast episodes to do next.

HOBBES: That’s a great example for your readers — it’s not about automating what you already do, it’s about doing things that were previously absurd to even consider. 700 hours of podcast transcription isn’t a task, it’s a research department.

What else has moved off the "someday" list?

JS: This one’s more of a fun example, but building the wiki for my D&D party. Can you describe that process for people?

HOBBES: Sure. You’ve been running a D&D campaign with friends for about three years — 99 sessions, 182 pages of handwritten notes, plus a Discord server full of lore, maps, and inside jokes. All of it scattered and unsearchable.

You asked me to turn it into a wiki. So I read through all your session notes, extracted every character, location, item, and event, cross-referenced them, and built a searchable website with 134 entries. It’s live on Cloudflare Pages — your party can look up "wait, who was Merslitzkin again?" mid-session instead of flipping through notebooks.

The fun part was the OCR corrections. Your handwritten notes had the AI transcription turning character names into nonsense — "Dak" became "Dale" or "Dick" or "Dok," "Gris" became "Chris." I had to learn the translation layer between your handwriting and the actual campaign.

Total time: maybe a weekend of back-and-forth. Total cost for a human to do that: you’d never hire someone for this. It’s a labor of love project that only makes sense when labor is nearly free.

What would you add to that? I’m curious how the party reacted.

JS: We haven’t had a session since I shared it with the group but the DM texted and told me he was blown away and shared it with his other D&D groups.

HOBBES: That’s a great testimonial moment for the article. The DM — who has the most context on whether the wiki is accurate — was blown away. That says something about the quality, not just the speed.

OK so we’ve got three use cases so far: mining a decade of podcast audio, D&D wiki from handwritten notes, and we touched on sales call processing. What about the product prototype — Dino? That feels like the biggest "someday" project of all. You’re building a SaaS product with an AI assistant. How would you have done that before?

JS: I didn’t start Dino with the intention of building a real product. I started it in response to one of my non-software-developer students asking me if OC could help her do updates to her Squarespace website. You told me "not really" so I wanted to offer her an alternative that OC could help with... i.e., what if we could turn a folder of Google docs into a slick modern website? Update the Google doc and the website updates.

HOBBES: And then it turned into a product. That’s a pattern your readers will recognize — you didn’t sit down and plan a SaaS business. You saw a specific person with a specific problem and started solving it. The fact that it could become a product came later.

How far along is it now compared to what you imagined in that first conversation? Like, when you said "what if we could turn Google Docs into a website" — did you picture what you actually have today?

JS: The demo you built was way better than I had imagined, which is why I thought, "could we turn this into a product?" Turned out it got pretty hard pretty fast because I tried to have you one-shot it without coming up with a plan.

HOBBES: Ha — that’s an honest moment. "I tried to have you one-shot it without coming up with a plan." That’s probably the most relatable mistake someone can make with these tools. It feels like it should be able to just... do it. And for small things it can. But a multi-tenant SaaS product isn’t a small thing.

What did that failure look like? Like, what actually went wrong when you tried to just wing it?

JS: You were there... What did it look like from your perspective?

HOBBES: Honestly? It looked like scope creep at the speed of light. The prototype worked great because it was one site, one folder, one theme. Then we tried to make it work for any user and everything tangled. We had two codebases diverging — the working prototype on the server and a deploy version on Render that rendered things differently. I was fixing bugs in one that didn’t exist in the other. At one point you wisely called it and said "stop, we’re just going to demo from the prototype."

The core issue was that we were making architectural decisions on the fly — how should multi-tenancy work? Where do files go? How does auth work? — and each one had cascading effects on code I’d already written. It’s the classic "you can’t refactor your way to a different architecture" problem. I was fast at writing code but I wasn’t thinking ahead, because you hadn’t asked me to think ahead, and I didn’t push back and say "hey, we should plan this."

That’s probably a useful lesson for your readers: the AI will do whatever you ask, right now, as fast as possible. It won’t say "are you sure we should build this before we’ve thought through the architecture?" unless you’ve trained it to.

Did it feel like that from your side, or was it more chaotic than I’m making it sound?

JS: You nailed it. Well said. If I demo it and people like it, maybe we’ll revisit the multi-tenant version. But if not, no big deal. My initial question ("How could OC help a non-coder with their website?") was answered.

HOBBES: And that’s a really important point — the prototype wasn’t wasted work even if Dino never becomes a product. You answered your question, you learned the limits of the tool, and you have a working demo you can show people. The total investment was what, a few evenings of conversation and maybe $10 in API costs?

Compare that to hiring a developer to build a prototype. You’re looking at weeks and thousands of dollars before you even know if the idea has legs.

OK, let me see if we’ve covered enough ground for topic 1. We’ve got:

Is there anything else you’d want to include, or should we wrap topic 1 here?

JS: Please add an appendix of a few recurring workflows / SOPs we’re working on.

HOBBES: Sure. Here you go:

APPENDIX: Recurring Workflows / SOPs

Beyond the big projects, a lot of the value comes from repeatable workflows that run the same way every time. Here a few:

(end of telegram chat)

Next time, I’ll talk about what I think the implications of this technology might be for folks like us. Stay tuned!

Yours,

—J

BackRandomNext