RRochak Shrestha

Case study · Feb 2026 to now

Kata Jaam

Founded, built and operated alone. An event-discovery product for Nepal, run day to day by an AI operations agent.

2,451 registered users, first on Google for "events in Kathmandu", ~196 search clicks a day, the first paid placements sold in month eight. One person, with agents.

2,451
users, 17 Oct 2026
#1
on Google, "events in Kathmandu"
~196
Google clicks a day
1,321
approved events in the catalogue
2 wks
idea to first store build
15 min
of my day the operation needs
Kata Jaam home screen on an iPhone
The app's home: tonight, this weekend, the scenes people follow.
Google results for events in Kathmandu with katajaam.com first
Search is the acquisition channel. Most new users arrive from Google.
A Kata Jaam event page on the web
Every event has a public page with structured data, a registration form and a map.

The problem

Kathmandu has a real nightlife, a running scene, concerts, screenings and festival events every week, and no single place that lists them. Plans lived in Instagram stories that vanish after a day. Organizers had reach only as far as their own followers.

I wanted the thing I kept wishing existed: open one app on a Friday and know what is on tonight. I also wanted to find out whether one engineer with AI agents could ship and run a two-sided marketplace alone.

What I built

A Flutter app on both stores, a public website that Google indexes deeply, an organizer portal, an admin panel and a set of Cloud Functions behind them all. The first version shipped to the stores two weeks after the first commit.

  • The app: home spine (tonight, weekend, scenes), a Google Maps view with named pins, event pages with Interested, calendar export, directions and a chat, crews for going with strangers, push notifications that are targeted rather than broadcast.
  • The web: every event, venue, scene and festival has its own page with JSON-LD, a static map and canonical rules for recurring series. This is where the users come from.
  • Organizers: claim your listing, run a registration form, see responses, message every registrant from one screen, buy a placement. Native ticketing is built and waits on the payment gateway.
  • Admin: a decision desk that shows what needs a human now, and nothing else. Everything the agents do lands here with an approve or reject.

The operation runs on agents

The part I am most proud of is not the app. It is that the company runs with about fifteen minutes of my attention a day. A set of Claude Code agents, each with a written brief, work the Instagram inbox and the email inbox, walk Instagram to find new events and import them through a CLI, review the catalogue for errors, draft the social posts, run a weekly SEO loop and a weekly retention loop, and write the day's report.

Every outward action files on an approvals desk first. The agents never publish, never message an organizer, never approve a listing without a human click. The hard limits are written down; the judgement is theirs. A nightly shift takes the bugs the day found and builds the fixes in an isolated worktree so I wake up to diffs.

I wrote more about how this works on the agents page.

Decisions that mattered

  • Search first, not social first. Instagram gave reach for a week at a time; a page that ranks gives it every day. Most signups say they found us on Google.
  • Interested is the one save signal. A separate bookmark split the data and taught nothing; it was merged and the counter became meaningful.
  • Notify, never ask permission. Organizers are listed, credited and told; a takedown is one click. Asking first meant no catalogue.
  • Keep the Admin SDK on REST on Vercel. The default gRPC transport wedged on reused instances and turned a cache into three million Firestore reads a day. One flag fixed the bill.
  • One tombstone for every deleted event, so a URL Google has already indexed never 404s into a lost ranking.

What changed after launch

Users went from 0 to 2,451 in eight months on no paid acquisition. The site holds first position for the head term and ranks for hundreds of long-tail event queries. Weekly planners, the north-star metric, grew 11 percent week on week in the most recent read. The first organizers paid for placements in October 2026.

The honest part: week-four retention sits under 10 percent, because most people plan one night and come back the next time they need a plan. The push rework and the scene follows exist to change that, and the number is still being read every Thursday.

What I would do differently

  • Build the organizer side before the consumer side. Supply is the harder half of a marketplace, and I learned it four months in.
  • Start with paid placements from day one instead of a free period. The free period taught organizers the feature was worth zero.
  • Write the engineering handbook from the first week. The gotchas file now prevents the same bug twice; the first three months had no such thing.

Have something like this in mind?

Describe it to the fit assistant. It cites this case study where it applies and says where it does not.