Skip to content
For MonkVenkatesh Kavali

Hi, Denny.

I want to work at Monk.

Quick context: I've been building backend systems for about seven years. For the last two, I've also been building things on the side — mostly because I genuinely enjoy it and get restless when I'm not creating something. This page is the short version of why I think we'd be a good match.

Before anything else — see what I'm building
// 01

Why Monk

The teams where I've actually grown have all been small and shipping fast. Short feedback loops. Direct conversations. The bar comes from the person sitting next to you, not from a planning doc two layers up.

From the outside, Monk looks like that kind of place. Fast, opinionated, technically serious. The kind of company I'd actually want to spend my time at, not just one I could survive.

I'd rather make a five-person team faster than be one more senior IC inside a fifty-person one.

// 02

How I tend to work

  1. Ship fast.

    I'd rather get something into a real user's hands and learn what's wrong than keep arguing about it in Slack. A working surface beats a perfect plan — the build log is the receipts.

  2. Get up to speed quickly.

    Drop me into a new codebase and I'll figure out how it actually behaves.

  3. Care about how it actually runs.

    Latency, throughput, cost. I think about these while I'm writing the thing, not in a follow-up ticket six weeks later when it's on fire — more on the systems side.

  4. Iterate, then iterate again.

    Whatever I ship is v1 of itself. It gets sharper because real people poke at it, not because someone scheduled a roadmap review.

  5. Take ownership.

    Happy to be the one who reads the gnarly file nobody else wants to touch and decides what to do about it. That's usually the highest-leverage work anyway.

// 03

A few projects

Three I'd point at if you only have a minute. None of them have real users. They're things I built to keep myself sharp. The rest are over on the home page.

Identity Orbit

In private beta
Details →

An identity-resolution prototype. Started after I got tired of watching real systems make bad merges because they only knew how to compare two strings.

What's in it
  • deterministic, probabilistic, and behavioral signals all feeding the same score
  • a proximity score that decays if a profile goes quiet and strengthens when it doesn't
  • an anomaly-review queue for uncertain merges instead of silently introducing bad identity links
  • designed for billion-record weeks. streaming and batch run side by side

vibeCodeScan

Open source · Building
Open ↗
vibecodescanner.dev

Open-source scanner for the bugs you keep finding in LLM-written code.

What's in it
  • Semgrep ruleset I keep adding to as I see new patterns. SSRF, missing authz, secrets in logs.
  • behavioral probes for prompt-injection holes and weird tool-call behavior in agent stacks
  • drops into a CI step. Exits non-zero if it finds something past the threshold you set.
  • open by default. Defenders need shared rules more than attackers do.

fetchlab

In private beta
Open ↗
fetchlab-production.up.railway.app

Recording, replay, and diffing for agent stacks. Because agent failures are difficult to reason about with traditional logging.

What's in it
  • every tool call, retry, and prompt mutation saved as a structured trace
  • diff a new run against a golden trace in CI. catches drift after a model bump.
  • replay is deterministic. tool responses, model versions, system prompts all pinned.
  • you see the exact step that diverged, not a transcript and a guess
// 04

Elsewhere

Outside work, I spend most of my time building. Sometimes that's AI tooling or systems experiments.

Other times it's landscape photography, competitive Valorant, or cricket — I've picked up a few MVP awards over the years. I like fast feedback loops, competitive environments, and figuring things out.

// 05

Reach

Email is fastest. I'll get back to you the same day.

vkavali10@gmail.comSee everything I'm building →Read my resume →LinkedIn ↗