Skip to content
Reldava Tech
All work

PulseRepo

What a repository says about the process that produced it.

Role
Sole engineer: analysis engine, AI layers, SaaS, deployment
Period
2025 - 2026
Status
Live shakedown
Live at
pulse-repo.com

An owner commissions software from an agency or a group of freelancers. There is no ticket system, no pull-request flow, no acceptance criteria - there is a git repository and a demo that looks like progress. PulseRepo reads the repository and says where to look and what to ask.

The top of a repository report: the analysed window and commit counts, a plain-language summary, and the same signals rewritten for an owner and for an investor.
One analysis read at two altitudes: the founder is asked who ships if one person is away, the board sees the same fact as a concentration risk.
The question feed: each item is a question tagged flag or watch, with an evidence line beneath it naming files, commit counts and the window.
Sixteen detectors produce questions rather than verdicts, and each one carries the evidence it was built from directly underneath.
The demo-risk section: a rule-based scan listing debug leftovers and the test-to-code file ratio, followed by an AI reading of that same scan.
The deterministic scan states what it found; the AI layer only turns it into questions, and says plainly which checks came back clean.

Questions, not verdicts

The output of the engine is a question with its evidence attached: this endpoint was rewritten twelve times, here are the commits, it is worth asking why. Never a judgement about a person.

That framing is an engineering decision as much as an ethical one. The atomic unit of output becomes a question rather than an accusation, which drops the precision bar by an order of magnitude and removes an entire class of legal risk. The cost of a false positive is a two-minute conversation.

The honest boundaries are stated in the product itself: a repository shows the shape of a process, not its causes; effort is not volume, and the most valuable change is often the smallest one; attribution is fragile, and the tool says so rather than pretending its data is clean.

The deterministic core

Layer one is git facts and nothing else - no network, no model, no code leaving the machine. Contributor profiles, ownership by area from blame at HEAD, rework hot spots, churn factor, a bus-factor anomaly feed, the feature surface, and the hygiene of the commit messages themselves.

File classification adapts per stack - Laravel, Python, JS/TS, Go, Java, C#, Rust, C++, Kotlin - detected automatically, with monorepos and non-framework layouts handled rather than assumed away.

What it found on a real repository

Validated against a Laravel monolith: eleven months, three developers, 1907 commits, with merge history intact so churn is visible honestly.

The developer with by far the most commits owned three per cent of the backend; the engine had been built by someone else, with fewer commits but 71 to 81 per cent of production code. That is not a ranking of people - it is the shape of a role, and the naive commit count inverts it completely.

A 24-line partial had been rewritten 24 times. One controller carried 87 commits. The owner of four fifths of the production code had last committed two and a half months before the window closed, which is a handover question with a date on it. Demo risk came back clean - no debug leftovers, no skipped tests, no hard-coded secrets - because a tool that can never say "this is fine" is not measuring anything.

Semantics, then AI, then a feed

Layer two moves the analysis from files to functions with tree-sitter, so growth and churn are attributed to the thing that actually changed.

Layer three adds models where they earn it: reconstructing work items from history when there is no ticket system, classifying commit intent, phrasing the summary. Split across a cheap model and an expensive one with a per-commit cache, and it is optional - the deterministic core delivers about eighty per cent of the value without any of it.

Layer four ranks everything into a feed of questions, with sixteen detectors and pull-request ingestion from GitHub and GitLab. There is also free-form question answering over the stored facts: a planner picks tools, a synthesiser writes the answer, and "what happens if the main developer leaves" is a question you can simply ask.

Local by default

Layers one and two run entirely on the machine holding the repository. The network is only touched by the optional AI layer, and the hosted SaaS exists for people who would rather not install anything - not because the analysis needs a server.

The hosted side carries accounts, four OAuth providers, asynchronous analysis jobs, history and trends across repositories, plan limits and an admin console on its own subdomain.

Stack

  • Python
  • Typer
  • tree-sitter
  • FastAPI
  • PostgreSQL
  • React
  • Docker
  • Anthropic
  • GitHub API
  • GitLab API
  • pytest
  • Vitest

Tell me what you are building

A description of the problem is enough to start. If it is a fit I will say what I would build, roughly what it takes, and what I would not do.

Discuss a project