This Week in Bottari #01

The week it started finding its own work. Building in public.

Three things happened this week. Looked at separately they're just a bug, a data pipe, and a test. Looked at together they're the whole bet: an AI that sees clearly, remembers continuously, and acts without being told.

1 / The bug that was never a bug

Our first green build landed this week. Sounds small. It wasn't.

Bottari only ships a build if our QA module scores it 100/100 — and QA doesn't trust the compiler. A build can compile perfectly clean and still render wrong. So it screenshots the running build and checks that the code actually became what it was supposed to become, on screen.

The vision model reading those screenshots was DeepSeek V4 Pro. Except it wasn't really reading them. It was grading a blank stare — and failing builds that were completely fine.

We spent hours sure it was our bug. Combing through code that had been working the whole time.

Then we swapped in Gemini Flash 2.5 Lite. 100, first try.

The lesson we keep relearning: when something fails, ask whether the model can even see what you think it's seeing — before you go rewriting the thing that was never broken.

2 / A memory that doesn't wait to be told

That bug is the whole problem in miniature. For an AI to do anything useful on its own, it first has to perceive reality correctly — and not once, but continuously.

So next we started wiring real data sources into Bottari's memory. We kept the first pass deliberately cheap — just scrape the App Store for app info and the reviews that keep coming up, enough to see if the loop even held. It held. Bottari pulled how users are actually reacting straight into the product's memory.

So now we're widening the pipe. Instead of scraping the surface, we're connecting the actual App Store and Google Play accounts — pulling downloads and revenue in alongside the reviews. Reviews tell you what users feel; installs and revenue tell you whether it's moving. A memory worth acting on should hold both.

Why this matters to us. A static memory means you're still spelling everything out for your AI. You read the reviews. You summarize them. You hand them over. Every time.

A living memory is different. If the memory is always aware of what users are saying, the AI stops waiting to be told. It can go find the work.

3 / The day it found work on us

Then the part that surprised us.

The piece behind this is the next-move module. Officially, anyway — we haven't settled on a name, so internally we just call it the Tari module, because Tari is the one that trots off and fetches the recommendation. It reads the stack we actually work in (Slack, Notion, Figma, GA) and pulls the next action on its own. This week it was only meant to be on trial. We were testing whether it worked at all.

It worked on us.

Bottari read our own Slack threads and Notion meeting logs and surfaced the next thing to do on Bottari itself: pull the onboarding a-ha moment earlier. The logic was sharp. Getting your first next-move recommendation is the a-ha moment of Bottari — so put it right after onboarding, up front, and let a new user feel what the product actually does as fast as possible. It quietly dropped that into our backlog.

And look at what that wasn't. Not "reply to this review." Not "fix this bug." It was a product call — how Bottari delivers its own core value, and how to make people feel it sooner. The kind of judgment you'd want from a PM, not a task queue.

The tool we were building made that call. About itself. Before any of us had written it down.

That's the whole bet behind Bottari. Builders shouldn't have to assign work to their AI every single time. The AI should find the work.

See clearly. Remember continuously. Act without being told.

This week we got a small, real version of all three. On to the next.