RRochak Shrestha

Build log · · Rochak Shrestha

What it took to get a company down to fifteen minutes a day

Eight months of running Kata Jaam with Claude agents: the three changes that mattered, the two that did not, and the number I still cannot move.

Kata Jaam is an event-discovery product for Nepal with a few thousand users. I run it alone, next to a full-time job, and for the last two months it has needed about fifteen minutes of my attention a day. That number is real and I want to be precise about what produced it, because most of what I tried did not.

The three changes that mattered

One approvals desk. Early on, each agent reported into its own file, its own channel, its own log. I spent my fifteen minutes finding the work instead of judging it. Now every loop files on one admin page, ordered by what needs me most: failed-after-approve first, then overdue, then decisions, then approved-and-needs-a-hand. Keys for approve, edit, skip. The badge counts only what needs me now. The desk is the product the agents build for me, and the rest is upstream of it.

Briefs instead of rules. My first agent prompts read like a flowchart. If the organizer says X, reply Y. They produced stiff, wrong-in-the-edge-case messages and I kept adding branches. The rewrite describes the job, the person on the other side, the tone, and a short list of hard limits, then trusts the model. The DMs got better the week I deleted the rules. The briefs are now revised weekly by a retro loop that reads the journal and proposes diffs, and I approve the diffs like any other row.

A CLI with no AI in it. Everything an agent writes to production goes through one small command-line tool that calls the admin's existing API. The tool has a dry run for every verb, refuses a likely duplicate, logs what it did, and contains no model call at all. The agent decides the fields; the CLI writes them. This split is what let me widen autonomy without fear, because there is exactly one path to production and I can read it.

Two things that did not

A real-time counter. An organizer asked how many people saw their event. I built a live counter with a second pipeline. It was over-engineered within a day; an on-demand read from the analytics tool answered the same question. I took it out. The lesson I wrote down: before building a second system, run the on-demand version of the first one against production and price the difference.

Automated Instagram ingestion. It worked technically and I turned it off. A scout agent that reads posts the way a person would, in my own browser, imports better events with fewer duplicates, and I can watch it. Scale was not the constraint; judgement was.

The number I cannot move

Week-four retention is under ten percent. People open the app when they need a plan for a Friday and come back when they need the next one, which for most is not a week later. Targeted pushes and scene follows exist to change this, and the Thursday retention loop reads the cohorts every week. I am writing this down so the next post has to report the number.

What I would tell someone starting

Build the desk first. Write briefs, not flowcharts. Put a dumb, audited tool between the agents and production. Start every loop with sending turned off and widen it with the approval rate, not with optimism. And date every number you publish, including the ones that are not moving.