·   ·   · 

First-year CS student at San Francisco Bay University. I build things that actually ship — with tests, migrations, signed webhooks, and an answer for what happens when they break at 3 AM.

Most of my time goes to developer infrastructure. I'm drawn to the problems where the popular tool is the wrong shape for the question — where everyone reaches for a vector index and the question was never about similarity.

The throughline in all of it is the same: the shape of the data decides which questions you are allowed to ask. Blast Radius stores one graph twice because traversal speed and forensic precision want different shapes. The cache keys on meaning because an exact-match key never hits on LLM traffic. Meridian tracks tax lots individually because an average cost basis makes harvesting advice quietly wrong.

Choose that wrong and no amount of application code rescues it. Choose it right and the query everyone told you was expensive collapses into one hop.

When an npm package is compromised, defenders have minutes to answer one question: who is actually exposed, right now?

Every AI dev tool shipping today indexes code as embeddings and retrieves by similarity. A transitive reverse-dependency closure is not a similarity problem — it is a graph traversal, five hops deep, over tens of millions of versioned nodes. Similarity cannot answer it. Not badly. At all.

So I built the thing that can.

The data model is the whole trick. Two layers in one graph: a collapsed Package-[:REQUIRES]->Package layer so traversal stays flat as depth grows, and a version-precise Release-[:DEPENDS_ON]->Package layer underneath so the forensic questions stay answerable. Traversal speed and forensic precision want different shapes — so I store both and let the planner pick.

_{Python · FastAPI · HydraDB (OpenCypher) · SQLite · Supabase · Docker · vanilla JS, zero build step
27k lines  ·  381 tests  ·  MIT  ·  built solo over a hackathon weekend for Hack Hydra}

Paris, 1858. Morphy is at the opera, playing two noblemen sharing a board. He gives away both rooks and the queen, and mates on move seventeen with the only two pieces he has left. It is the game people are shown to learn that development and tempo beat material — that what you have matters less than what it can reach.

Four rules I hold every project to. They're unglamorous, and they're where most of the real decisions end up.

No mocked data. Anywhere. Every number on every screen comes back from a query that was actually run — including empty states. A demo that lies is worse than no demo.

Measured, not claimed. Every panel in Blast Radius carries the latency of the query that produced it. If I say it's fast, there's a number next to the claim.

Secrets are a design problem, not a checklist item. From that repo's .gitignore, verbatim:

# Deliberately a glob: .env.production was not covered by the explicit list,
# which is the failure mode this pattern exists to prevent.

# SQLite side files, for every database this project grows. Listing each one by
# name has already failed once: the -shm and -wal here were git added first and
# ignored second, and .gitignore does not apply to anything already in the
# index, so they stayed staged and would have been committed.

Commits explain the change, not the diff. Answer the lockfile question from the lockfile. Keep the site up when its dependencies are not. You can read the history and know what happened.

I'm a freshman, I move fast, and I'd rather build the hard version. If you're working on graph systems, agent infrastructure, or developer tooling — or you want someone who ships over a hackathon weekend and still writes the tests — I'd like to hear from you.

rohitmaruriats@gmail.com  ·  open to internships, hackathon teams, and OSS collaboration