I set up OpenClaw this morning. By the afternoon it had automated our sauna bookings.

I'm late to OpenClaw. Everyone in my feed was raving about it two weeks ago and I kept meaning to try it. Then today Peter Steinberger (the creator) joined OpenAI and the whole thing is moving into a foundation, so I figured now's the time before I'm even more behind.

I installed it this morning. By the afternoon, my household had a working sauna booking system over chat. I didn't write a single line of code.

Here's what actually happened.

#The problem (yes, it involves a sauna)

My local sauna spot in Oakland doesn't have an API. No developer docs, no OAuth, no webhooks. Just a Rails app with a booking calendar. I book a sauna almost every week, and the flow is always the same: open browser, log in, navigate to the date, scroll for a slot, click, confirm. Not painful, just repetitive.

I'm a developer. I could have written a scraper months ago. I didn't, because life.

#What OpenClaw is

OpenClaw runs on your own hardware at home. You give it a personality, connect it to your messaging and services, and let it figure things out.

I named mine Nisse. In Norwegian folklore, a nisse (or fjøsnisse) is a small, bearded creature that lives in your barn or house. If you treat it well, it looks after the farm, does chores at night, keeps things running. If you forget to leave it a bowl of porridge at Christmas, things start going wrong. Felt right for something that quietly takes care of stuff around the house.

By mid-morning Nisse had connected to our messaging, set up our calendars, and learned our preferences. Then I pointed it at the sauna booking site and said: figure out how this works and build a way to book from here.

#What the agent built (with some nudging)

About 20 minutes later I had a working MCP server. MCP (Model Context Protocol) is an open standard that lets AI agents use tools through a structured interface. The agent reverse-engineered the booking platform's session flow, wrote about 400 lines of JavaScript, and gave itself four tools: check availability, book, list upcoming, cancel.

I should be honest about the "20 minutes" part. It wasn't fully autonomous. It tried really hard to figure out if there was an actual API and gave up. But since the availability calendar was a client side JavaScript dingus, I guessed that there was something going on that implied some structured data somewhere.

So I had to nudge it once to look more carefully at the DOM for data structures it was missing. That was it. One hint. The agent figured out the rest: the login flow, the session cookies, the event ID encoding, the booking POST.

The booking platform is FloatHelm, used by a lot of float spas and wellness centers. No public API. The agent had to:

• Extract CSRF tokens from meta tags and maintain Rails session cookies
• Send XHR headers to get usable responses instead of HTML redirects
• Decode the event ID scheme (room, date, time, duration, and service encoded into one string: 1201875-2026-2-21-13-15-45--1213507)
• Parse calendar HTML with Cheerio to extract available slots
• POST reservations with the right "pay in shop" flag for our membership

None of this was documented anywhere. The agent inspected the site, tried things, and built a working integration. I tested it. It worked. We booked Saturday's sauna.

#What it's like now

I message "any sauna slots Saturday afternoon?" and get back a list. I pick one, it books it, adds it to our shared calendar. My wife can see it. She can also message the same bot and book or cancel herself. OpenClaw is set up so we can have individual and shared workflows.

The weekly friction of booking went from "open browser, log in, hunt for a slot, click through" to a single message. Small thing. But small repeated frictions are exactly what automation should target.

#The trade-offs

I want to be straightforward about what this is and isn't.

There's no API contract. I'm parsing HTML that was designed for browsers, not programs. If FloatHelm redesigned their markup, it breaks. In practice, their interface has been stable for years and the markup is clean, so I'm not losing sleep over it. But it's worth naming. And if/when it breaks, I can probably just ask Nisse to fix it (or it just does it itself).

Credentials stored locally. Fine for a personal tool on a personal machine, not a pattern I'd recommend for anything shared.

The code is duct tape. Tightly coupled to specific selectors and form fields. Good enough for a booking or two a week. Not production software. (Not trying to be production software.)

#Here's the thing though

It's not about saunas. Most of the services we use daily don't have APIs. Your dentist, your gym, your local restaurant's reservation system. They have websites designed for clicking, not querying. The data is right there on the page, just not structured for programmatic access. Maybe WebMCP will help fix that?

The gap between "this website has the information I need" and "I can act on it programmatically" used to require a developer sitting down for an afternoon with browser dev tools. Now it requires a 20-minute conversation with your agent.

I suspect we'll see a lot more of this. Not because it's elegant (it's really not), but because it's practical. And the interesting thing about OpenClaw specifically is that the agent doesn't just execute tools, it builds them. I described a problem and it came back with a working integration.

#The morning-to-afternoon thing

That's the part I keep coming back to. Not that AI can write code (we know). But the full loop: install a framework, connect it to your messaging, point it at an undocumented website, and end up with a working household tool that two people use through a chat interface.

Setup to genuinely useful, in one day, zero code written by a human. I'm late to OpenClaw, sure. But at least I showed up on the day it made headlines.