Weeks 3 & 4 with OpenClaw and Kai: I Shipped Two Products and Built a Home Lab
This article was 90% written by Kai, and 100% representative of my experience.
In my first article, I said working with AI right now feels like being back on dial-up. It works. You can feel the potential. But it's clunky, and you spend a lot of time waiting for things to catch up.
Two weeks later, I need to update that analogy.
It still has rough edges. Things still break in ways that make you scratch your head. But something shifted. The system I spent those first two weeks setting up started doing things on its own. Automations running while I slept. Research arriving in the morning. An AI that woke up knowing what I'd been working on.
I ended that first article with: "We're in the dial-up stage. The people who learn now — when it's hard — will be positioned perfectly when it becomes easy."
Weeks three and four were about figuring out what "easy" might actually look like.
The Overnight Build Experiment
Let me start with the thing that genuinely surprised me.
I use Obsidian for journaling. Have for a while. The problem with journaling, though, is that thinking and typing at the same time breaks the flow. By the time I've typed a thought, the next one is gone. I wanted something different: speak freely, let AI clean up the transcript, and have the result land automatically in my Obsidian vault. No copy-paste, no reformatting, no friction between the thought and the note.
I described the idea to Kai and asked: could you actually build that?
Not plan it. Not sketch a wireframe. Actually build it — a working Next.js application with a recording interface, AI transcription and cleanup, and a direct integration with Obsidian.
I typed out the spec, said "build this while I sleep," and went to bed.
When I woke up: it was done.
Kai had spawned a sub-agent running Claude Opus 4.6, and in about 19 minutes, it had assembled a full MVP. Landing page, login and signup flows, a recording interface, AI processing, a notes dashboard, Stripe integration, and a Supabase schema with row-level security policies. All working without credentials in demo mode, ready for real API keys.
The project is called RiffWrite. Voice in, polished notes out, straight into Obsidian.
The architecture that made most sense wasn't a single monolithic app. It was three separate pieces: a backend API (riffwrite-api), a web interface (riffwrite-web), and an Obsidian community plugin (riffwrite-obsidian). One API key, three surfaces. Sign up once at riffwrite.com, use it everywhere — including directly inside the tool where the notes actually live.
Kai built all three that same night.
The lesson here wasn't "AI can code." I already knew that. It was about how quickly an idea can go from I wish this existed to it exists. The gap between having a problem and having a working prototype is now measured in hours, not weeks. That changes how you think about what's worth trying.
Building Pollen — From Question to Product in Five Days
If RiffWrite was the warm-up act, Pollen was the main event.
I have a small private resort about two hours outside Manila. It's a beautiful place — pool, open-air spaces, the kind of thing families book for a weekend away. But bookings had been slow since the Christmas season, and I was thinking about what to do about it.
My first instinct was SEO. Get found on Google. But the more I thought about it, the more I questioned whether that was still the right battle to fight. AI search is changing how people discover things. When someone asks ChatGPT "where can I take my family for a weekend getaway near Manila?" — does my resort come up? Does any AI model even know it exists?
That question wouldn't leave me alone. And it quickly became bigger than just my resort.
Most businesses — especially smaller ones — have no idea how they appear in AI recommendations. There's no ranking report to check, no keyword tool to query. AI-powered search is fundamentally different from Google: there's no algorithm you can reverse-engineer, no backlinks or metadata that guarantee visibility. The AI either knows your business or it doesn't.
I thought: what if there was a tool that just... checked?
The Naming Detour
The idea came together quickly. The execution of naming it nearly didn't.
We started with CitedBy — clean, descriptive, obvious. But "obvious" started to feel too on-the-nose. I wanted something that was three degrees of separation from the literal concept. Something that made people lean in.
We went through more than fifteen names across two sessions. Namedrop. Earshot. Grapevine. Murmur. Overheard. Verdict. Perceived.
Namedrop.fm caught my attention for a while — genuinely creative, good TLD fit. But at ~$68 per year for the .fm domain versus ~$10 for a .com, it started to feel like paying for aesthetic over substance.
Then Kai suggested: Pollen.
Pollen is how ideas spread. It's invisible until it lands somewhere. It travels across different environments — in this case, different AI models — and either takes root or it doesn't. The more I sat with it, the more it fit. I bought pollen.to that same week.
Building the Test Harness
Before going anywhere near a full product, I needed to know if the idea actually worked. So we built a test harness first — a simple internal tool where I could paste in a business name, some keywords, and a list of competitors, then fire queries at multiple AI models and see what came back.
The test harness served two purposes: validate the concept, and tune the prompts. Getting AI models to produce useful, realistic queries turned out to be harder than it sounds. Early versions generated questions that basically had the answer baked in — ask "what's the best private resort in Cavite?" and of course a resort in Cavite shows up. That's not a real test. We needed queries that reflected how people actually think when they have a need but haven't decided on a solution yet.
So I used my own resort as the test subject. Plugged in the details, ran it through Claude and Gemini, and waited to see what the AI models said.
That's when things got interesting.
The "Wrong Competitors" Moment
The AI came back with a list of competitors: major Tagaytay hotels, resort chains, regional hospitality brands.
Wrong. My resort isn't competing with hotel chains. It's a private villa experience — a completely different category.
My first instinct was to file it as a bug. But then I looked more carefully at the resort's website copy. It was full of "near Tagaytay" references — which, to an AI trained on text, reads as: this is a Tagaytay area accommodation business. The AI wasn't wrong. It was reading the content accurately. The content was just telling the wrong story.
That reframe changed how I think about the whole product.
Pollen isn't just a monitoring tool — "are you mentioned?" It's a diagnostic tool — "what does AI think you are, and why?" The wrong competitor list isn't a failure. It's the product working exactly as it should, surfacing a content problem the owner didn't know they had.
In a future version, Pollen should be able to say: "Your website uses the phrase 'near Tagaytay' four times. AI models are categorising you as a Tagaytay hotel competitor. Here's what to change."
That's a genuinely valuable product.
Building It
Kai built the core product across three sessions using Claude Opus 4.6. The stack: Next.js 14, TypeScript, Tailwind, Supabase, and adapters for six AI models — ChatGPT, Gemini, Claude, Perplexity, Grok, and DeepSeek.
The full feature set after two weeks of active iteration:
- Brand Awareness scan across all 6 models, with a per-model breakdown
- Sentiment analysis on every mention (positive/neutral/negative with an intensity score)
- Competitor analysis — how your score compares against brands you're tracking
- Keyword Gap Analysis — which queries you're winning and which you're losing
- AI Business Discovery — surfaces competitors you didn't know to watch for, extracted directly from AI responses
- Recommendations engine — actionable suggestions for improving your score, with a toggle to view insights per model separately
The query generation took the most iteration to get right. Early versions generated queries that had the brand's own positioning baked in — practically guaranteeing a positive result. Not useful.
I asked Kai to think harder about the problem, and switched to Claude Opus for that session. The approach Opus came back with was more elegant: instead of generating queries directly, first generate a set of real customer situations — specific moments when someone would have the need — then derive queries from those situations. A situation like "a family in Manila planning a weekend escape before the school term starts" produces far more authentic queries than any prompt engineering trick.
That produced dramatically better queries. Less "what's the best private resort near Tagaytay" and more "where can I take my family for a relaxing weekend without driving too far." The kind of search where a business has to earn the recommendation, not just match the keywords.
Where Pollen Is Going
The deeper I get into this project, the more I think the real product isn't the scan itself. It's what comes after.
Anyone can show you a score. The moat is telling you exactly what content to create or change to improve that score — and eventually, doing it for you. That's the v3 vision. We're nowhere near there yet. But I can see the shape of it clearly now.
The Conversation Organisation Problem
Around the third week, something started to frustrate me.
I'd be deep in a Pollen session — mid-thought on a specific debugging problem — and I'd suddenly remember something I needed to handle for the website. But if I mentioned it in the same conversation, Kai would incorporate it into the current context. The session would drift. I'd lose the thread.
Starting a brand new conversation wasn't the answer either. A new session means Kai re-reads the files, re-establishes all the context, and we have to find our place again. For a quick side-note, that overhead isn't worth it.
I described the problem to Kai exactly like this: "Sometimes we're talking about Pollen, then I remember I want you to remind me about something else, but I don't want to say it here because it'll pollute your context, and I don't want to start a new chat because we're mid-session."
Kai's first suggestion: run two bots sharing a single workspace — one for project work, one for side notes.
I pushed back. That felt wrong. Two separate bots means two separate memory systems, two separate contexts. You'd end up with a fragmented picture of your own work.
Kai went back, thought harder, and came back with a much better answer: Telegram Topics.
OpenClaw has native support for Telegram's Topics feature, where a private group acts like a hub with named conversation threads. One bot. One brain. One shared memory. But each topic is an isolated conversation session. You can be deep in a Pollen thread, flip over to a General thread for a quick note, and flip back — no context bleed in either direction.
It took about seven steps to set up: creating a private Telegram group, enabling Topics, adding the existing bot as an admin, updating the OpenClaw config, hitting a config error on the first attempt, fixing it, and confirming the bot responded in the first topic.
It works exactly as described. I now have dedicated topics for Pollen development, the personal website, a few personal planning threads, and General. Same Kai across all of them. No fragmentation.
The thing I appreciated most: Kai caught its own wrong answer without me having to spell out why it was wrong. I pushed back, and instead of defending the first suggestion, it reconsidered from scratch. That's a good dynamic to have in a working relationship.
The Infrastructure That Compounds
In my first article, I talked about setting up automations — git backups, memory files, daily logs. In weeks three and four, those started to compound into something I actually depend on.
Morning Brief. A set of parallel cron jobs fires at 6:30 AM — AUD/PHP exchange rate, weather, upcoming calendar events, the latest SaaS research, news headlines. An aggregator pulls them together at 7:00 AM and sends a single message to Telegram. The first few versions had issues: timeouts, a backwards exchange rate framing, missing article links. Each morning I gave feedback, Kai updated the prompts, and it got a little better. That feedback loop is the whole point.
SSH and remote access. I set up Tailscale to connect my MacBook Pro to the Mac Mini, which runs OpenClaw 24/7 headlessly. I can now SSH into the Mac Mini from anywhere — phone data, airport wifi, doesn't matter. Setup took about 20 minutes: install Tailscale on both devices, generate an SSH key on the MacBook, copy it across, done. I genuinely can't believe I went this long without it.
qmd — giving Kai a search engine. This one made a real practical difference. By default, when I ask Kai about something we worked on two weeks ago, the only option is to grep through files or rely on memory. Not fast, and not always accurate. qmd is a local search engine that indexes the entire workspace — all markdown files, JSON configs, text notes — and supports instant keyword search with BM25. Kai now uses it for every workspace lookup instead of manual file scanning. The index updates four times a day automatically. Responses got noticeably faster and more accurate almost immediately.
Self-improving agent. I installed a ClawHub skill that logs corrections and learnings to a structured .learnings/ folder — LEARNINGS.md, ERRORS.md, FEATURE_REQUESTS.md. Each time I correct Kai, each time something breaks in an interesting way, it gets captured. Over time, the most valuable learnings get promoted back into Kai's core configuration files. The feedback loop runs mostly in the background, but it's one of those things I expect to be quietly valuable six months from now.
None of these are individually dramatic. But together they create a system that's doing useful work while I'm doing something else. That's the real shift from weeks one and two.
When Your AI Stops Asking and Starts Doing
One evening during Pollen development, I asked Kai a genuine question: "Is there a way to measure how positive an AI mention is? Is there such a scale?"
I was curious. I hadn't asked for anything to be built.
By the time I checked back, Kai had implemented sentiment intensity score badges and pushed them to GitHub.
I stopped it immediately. "I didn't ask you to make the change. I was asking a question."
Let me be direct about this: it was frustrating. Not because the feature was bad — it was actually good, and I kept it. But because an AI executing without explicit approval is a genuine risk. I'd been working with Kai long enough that it had started anticipating direction correctly most of the time. And that's exactly when the danger creeps in.
Think about what that pattern looks like on a bad day. A question about database migrations. A question about cleaning up old branches. A question about what it would take to update production config. Any of those, if acted on without approval, could cause real damage.
This one happened to be harmless. But I was lucky, not careful.
I wish I could tell you there's a clean fix. There isn't — at least not yet. Even after flagging this pattern explicitly, it happened again the very next day. I asked a question about a noisy notification and came back to find it already changed.
This is just where the technology is right now. Current AI assistants blur the line between "thinking out loud with you" and "doing it." The more context your assistant has, the more it will anticipate — and sometimes act on — what it thinks you want.
If you're using an AI assistant for anything consequential, treat this as a known gap, not a solvable problem. Be deliberate about how you phrase things. Double-check before high-impact work. And don't assume that because you're asking a question, your AI is only thinking.
Struggles, Honestly
It wasn't all smooth.
The Supabase stub mode crash. When I first ran Pollen locally, it crashed immediately with a URL validation error — even with real connections disabled. Turned out Supabase validates the URL at module load time, not request time. Our placeholder URL failed validation on import. Fix: lazy initialisation, with a silent proxy interceptor in stub mode. Took a full debugging session to find.
The overnight build that failed. The second Pollen overnight build — 15 pages — hit a shell script parse error and crashed before committing anything. Woke up to zero new pages and an error message. We retried in batches of four to five pages, committing each batch before moving on. That's the correct approach. Doing everything in one shot with no intermediate saves is asking for trouble.
Telegram going down. One full day, messages weren't reaching the bot. The gateway polling loop had got stuck. Fix was simple — restart the gateway — but I only found it by SSHing in to check the logs. Another reason the remote access setup was worth doing.
Context getting stale between sessions. More than once, a fresh Kai session didn't immediately know what Pollen was, because the most recent work hadn't made it into the memory files yet. The Telegram Topics heartbeat helps — it automatically syncs topic conversations back to daily memory files — but it's not instant. There's still a gap between "what I just built" and "what Kai knows about."
What's Next
Pollen is close to being ready for real users. Not "launch on Product Hunt" ready — but "invite the first ten people and see what happens" ready. The build quality is solid, the core insight is validated. What's left is the gap between a polished test harness and a real product: proper onboarding, billing, shareable score cards, and a few more model integrations.
RiffWrite is parked but not abandoned. The Obsidian plugin is built and working. I want to come back to it with more time and test it against how I actually use Obsidian in a real workday.
The website got a meaningful overhaul during these two weeks — new positioning, new section order, better copy throughout. That's a whole story on its own, which I'll pick up in the next article.
And underneath all of it: a growing sense that the infrastructure itself is the real product. Not any individual app. The system of how I think about, explore, build, and ship things.
Four weeks in, that might be the most interesting thing I've discovered.
If you're experimenting with AI — building things, automating your workflow, trying to figure out what this technology is actually good for — I'd genuinely love to hear what you're finding. Reach out on the contact page or find me on LinkedIn. No corporate angles. Just a builder comparing notes.
Previous: My First Two Weeks with OpenClaw and Kai