Skip to main content
Version: v2 (current)

Product overview

TL;DR. Git shows you the artifacts of finished work — commits and PRs. Jira tells you what people say they are doing. Neither shows you what actually happens between those two snapshots. PanDev Metrics is the glue between Git, Jira, CI/CD and the IDE — and the only platform that turns those signals into the real cost of a feature.

The problem: Git plus Jira is roughly 40% of the picture​

Engineering leaders run on two main data sources, and both lie to them in different ways.

Git is a rear-view mirror. Commits, pull requests, merges — they only appear after the work is already done. They tell you nothing about the days an engineer spent debugging, pairing, reading code, switching contexts, or waiting for a review. By the time a commit lands, the interesting decisions have already been made.

Task trackers drift. In our experience working with mid-size and large engineering orgs, Jira (or any other tracker) reflects reality in about 30% of cases. Statuses go stale. Work gets done off-ticket. Tickets get moved retroactively. Half-finished tasks sit in In Progress for weeks.

Put the two together and you get, optimistically, 40% of what's really happening in the org. The remaining 60% — actual coding hours, debugging time, AI-tool usage, focus blocks, context switching, deep work — lives inside the IDE. Nobody else collects it.

That missing 60% is what PanDev Metrics is built for.

How PanDev Metrics solves it​

PanDev Metrics ingests signals from three independent layers, normalizes them into one timeline per engineer, and attributes events to the org tree (tenant → department → team → person).

The IDE layer is the part everyone else skips. Our JetBrains, VS Code, Visual Studio, Xcode and Eclipse plugins emit file-level activity events — opens, edits, idle, foreground app — with the rule that any gap under 15 minutes counts as active coding and anything over 15 minutes does not. That single calibration is the foundation of every "real hours" number on the dashboard.

The Git layer attributes commits, PRs/MRs, reviews, and merges to people via email matching plus your employee directory.

The task-tracker layer maps issues, transitions, and time-in-status to the same people and projects. Repository = project; teams are nested inside departments.

Once all three layers share an identity model, the platform can answer the question that nobody else can: how many real hours did this feature cost, and what did those hours buy?

Key capabilities​

A short list of what the product does — see Features for the full breakdown.

  • Cost per feature. Direct cost of a task = time spent on it × the engineer's hourly rate, plus a proportional share of their unattributed time. The only metric on the market that actually answers "what did that feature cost?"
  • DORA metrics. Deployment frequency, lead time for changes, change failure rate, MTTR — performance bands included.
  • Real IDE hours. Coding, debug, AI-tool prompts, deep-work blocks, overtime (any work outside business hours on a weekday counts as overtime).
  • People & projects. Employee cards, project pages, departments, teams — every metric drills down to the source events.
  • Cloud and on-premises. Identical product. Cloud adds multi-tenant orgs and Google sign-in; on-prem ships as Docker / Kubernetes inside your perimeter.

Who it's for​

PanDev Metrics is a good fit if:

  • You have 10 or more engineers and the org is starting to feel chaotic.
  • You care about data-driven engineering management — not vibes.
  • A meaningful share of your work happens in an IDE on a stack we support (JetBrains, VS Code and its forks, Visual Studio, Xcode, Eclipse-family).
  • You need clean answers to "who is doing what, what does it cost, where are we slow."

Who it's not for​

We're honest about the fit. PanDev Metrics is not for you if:

  • Your org is not engineering-led (no significant codebase).
  • Your team works on a stack we don't support with IDE telemetry.
  • You're a security or DevOps-only team that rarely writes code — there isn't enough IDE signal to make the platform useful.
  • You explicitly do not want detailed activity data on engineers (we surface individual-level events alongside aggregates).

How we compare​

We invite the comparison. Q120 of our internal positioning guide is "yes, name competitors directly."

AspectPanDev MetricsLinearBJellyfishFaros AIWakaTime
Git + task tracker analyticsyesyesyesyespartial
Native IDE telemetry (JetBrains, VS Code, Visual Studio, Xcode)yes, full depthnononoyes, lighter
Cost per feature in $yes, primary use casenopartialnono
On-premises deploymentyesno (SaaS only)no (SaaS only)partialno
Multi-tenant cloudyesyesyesyesyes

Where competitors are stronger: they've been on the market longer and have larger reference customer lists. Where we win: on-prem, IDE depth, and the cost-of-a-feature loop.

The shortest version of the pitch we use internally:

We're the only system that can tell you exactly what a feature that your engineers built actually cost. If you've got more than 10 programmers, the chaos starts — and we show you who is really doing what, not "Status: In Progress."

Where to next​

  • Features — the full functional surface area.
  • Use cases — role-by-role stories: CTO, engineering manager, finance, HR, 10-dev startup, 200-dev enterprise.
  • Release notes — what shipped recently.
  • Quick start — install and connect your first source.

Citations​