# Live metrics on a personal site

> GitHub, products, and users. What to show, what to hide, and how to keep numbers trustworthy.

- Author: Kevin Dalvi
- Published: 2026-08-04
- Read time: 5 minutes
- Tags: engineering, metrics, portfolio
- Canonical: https://www.kevindalvi.com/blog/metrics-that-matter

Putting live numbers on a personal site feels like a dare. Either the counters look impressive and people distrust them, or they look small and you wonder why you bothered. I still show them. Quietly. With rules.

Metrics on a portfolio aren’t growth theater. They’re a credibility check. If I claim I’m building, the site should be able to prove activity without a LinkedIn thread.

## What earns a spot on the homepage

I only surface numbers I can explain in one sentence and refresh without manual lying. Product users. Public commits in a window. Live products. That’s mostly it. Vanity stars and ‘impressions’ stay off the board unless they map to a decision someone else cares about.

GitHub contribution graphs are optional decoration. What I care about is whether a visitor can map a number to a product card without squinting. If the metric floats without a noun attached, it’s theater. Delete it.

- Prefer rates and cohorts over lifetime tallies when possible
- Label the source. GitHub, Stripe, product DB. Next to the number
- Update on a schedule; never hand edit a ‘live’ figure
- Hide anything you’d argue about in diligence

> A metric you can’t defend in a meeting shouldn’t decorate your homepage.

## Trust is a design problem

Presentation matters more than people admit. Huge animated counters scream manipulation. Small, monospace figures next to plain labels feel like instrumentation. I treat the metrics strip like a status panel, not a billboard.

When a number dips, I leave it. That dips and all rule is the whole point. A portfolio that only rises trains visitors to assume fiction. Founders who show the ugly weeks tend to get better conversations. The ones about systems, not screenshots.

I also refuse blended metrics. ‘Users’ that mix free and paid, or ‘products’ that count abandoned prototypes, are how trust leaks. If I need two numbers to tell the truth, I show two numbers. Or I show none.

## Keep the pipeline boring

Technically, I want the least clever path: scheduled pulls, cached JSON, obvious fallbacks if an API fails. Clever dashboards die. Boring panels survive. If the fetch fails, show a dash and a timestamp. Don’t invent yesterday’s glory.

Live metrics won’t close a round. They will filter people who only want a story from people who want a builder. That’s enough reason to keep them honest. And to keep the plumbing dull enough that honesty is the default path.
