DEV Community: Jura

Your product has features nobody uses. Here's how to find them automatically.

Jura — Tue, 16 Jun 2026 14:56:50 +0000

Eight months ago I was in a product review meeting where someone asked: "does anyone actually use the bulk export?"

Nobody knew. The PM checked Mixpanel. The event wasn't there. Someone said it might be tracked under a different name. We ended up skipping the question and moving on.

Two weeks later, the same thing happened with a different feature. Then again.

That's when I understood the real problem — and it wasn't "we need better analytics."

The actual problem isn't the data. It's the catalog.

Every analytics tool I've used works the same way: you decide what to track, you add .track() calls, data starts flowing. The tool shows you what events exist.

But what about features that were tracked under the wrong name? What about the helper function someone added six months ago that wraps the SDK — did it ever get registered in Mixpanel? What about the feature that was renamed in code but the old event name is still in the dashboard, looking alive?

You can't find dead features if you don't have a reliable catalog of what features exist.

That's the gap I kept running into. And that's what I tried to fix with Eventra.

The insight: build the catalog from the code

Instead of asking teams to manually define what they track, Eventra reads it from the TypeScript codebase itself.

The CLI uses the TypeScript compiler API to scan your project and find every eventra.track() call — including through wrapper functions, re-exports, and barrel files.

Let me show you what that means in practice.

Say you have this in your codebase:

// lib/analytics.ts
import { Eventra } from "@eventra_dev/eventra-sdk";

const sdk = new Eventra({ apiKey: process.env.EVENTRA_KEY! });

export function trackFeature(name: string, userId?: string) {
  sdk.track(name, { userId });
}

// features/export.ts
import { trackFeature } from "@/lib/analytics";

export function handleExport() {
  trackFeature("bulk_export", currentUser.id);
}

Most analytics tools would never know trackFeature wraps the SDK. You'd have to manually register it. Eventra finds the chain automatically:

npx @eventra_dev/eventra-cli sync
# Scanning...
# Found 14 events, 1 function wrapper (trackFeature → eventra.track)

It does this by building a semantic model of your code — resolving imports, following the call graph, extracting what string each name argument resolves to. Not a regex pass. The actual TypeScript compiler API.

Dead features fall out naturally

Once you have a complete, code-derived catalog, dead feature detection is trivial: which catalog entries have had no events in the last N days?

The dashboard surfaces these in a dedicated view. No configuration. No manually defining what "dead" means. The data tells you.

What's more useful is the three-state classification:

Active — at least one event in the last 14 days
Dead — had events before, nothing recently. This is your deletion list.
Never seen — in your code, never reached the platform. Misconfigured, unreachable, or behind a flag that never fires.

That third state was the one that surprised me most when I built this. Features that exist in code but have never, in the history of the product, produced a single event. Either they're behind a toggle that was never turned on, or the tracking is broken, or the feature is so buried nobody found it.

Keeping the catalog in sync: CI integration

The catalog drifts. You add a feature, forget to run sync, and now the dead feature list is incomplete. Or you remove a feature but the old name stays in the catalog, giving false confidence that something is being tracked when the code is gone.

The check command is the CI gate:

npx @eventra_dev/eventra-cli check

It compares the current state of the codebase against eventra.json (the committed catalog snapshot) and exits 1 if they differ:

Checking events and function wrappers...

Events:
+ new_feature_name   ← in code, not in catalog
- old_feature_name   ← in catalog, removed from code

Add this to your CI pipeline and the catalog never drifts without someone noticing.

The SDK side

The CLI handles catalog management. The SDK handles runtime events.

import { Eventra } from "@eventra_dev/eventra-sdk";

const eventra = new Eventra({ apiKey: "your-key" });

eventra.track("bulk_export", { userId: currentUser.id });

A few things worth mentioning about the SDK implementation that I'm happy with:

Zero dependencies. The whole thing — batching, retry with exponential backoff, circuit breaker, browser localStorage persistence, multi-tab leader election — is implemented with no runtime dependencies. Works in browser, Node.js, edge runtimes, and serverless.

Circuit breaker. After 5 consecutive delivery failures, the SDK stops sending for 5 seconds. This prevents hammering a struggling API endpoint and burning through retry budgets. When the cooldown expires, one request goes through in half-open mode. If it succeeds, the circuit closes.

Browser multi-tab coordination. If you have multiple tabs open, only one tab (the "leader") flushes events to the server. The queue is shared via localStorage and BroadcastChannel. This prevents duplicate events from tab-heavy users and reduces server load.

Graceful shutdown. In Node.js, the SDK registers SIGINT/SIGTERM handlers and flushes the queue before the process exits. In the browser, it listens to visibilitychange and pagehide. Events sent just before the user closes the tab actually arrive.

The ingest pipeline

On the server side, the bottleneck I was most worried about was write throughput. Feature events can arrive in bursts — a deploy goes out, users start using a new feature, thousands of events arrive in seconds.

The solution is PostgreSQL's COPY FROM STDIN with pg-copy-streams. Instead of individual INSERT statements, events are written to an in-memory buffer, drained in batches of up to 5,000 rows, streamed into a temp table, and atomically upserted with deduplication:

INSERT INTO analytics."FeatureEvent" (id, "projectId", ...)
SELECT t.id, t."projectId", ...
FROM tmp_events t
INNER JOIN registry_insert r
  ON r."projectId" = t."projectId"
  AND r."idempotencyKey" = t."idempotencyKey"

The IdempotencyRegistry table handles deduplication: if the SDK sends the same event twice (retry after a timeout), the second insert is a no-op. Clients use UUID v4 as the idempotency key, generated client-side.

If the database goes down, batches spill to disk (atomic tmp-rename write) and are recovered on restart. The API returns { success: true } as soon as events hit the in-memory buffer, so ingest latency stays low regardless of what the database is doing.

What I learned building this after work for 6 months

The CLI was the hardest part. The TypeScript compiler API is powerful but the documentation is thin. The wrapper propagation system — tracking which function parameter maps to the event name, across files, through re-exports — took multiple rewrites to get right. The breakthrough was treating ts.Symbol as the canonical identity and using WeakMaps keyed on symbols for all caches. Once I had that foundation, incremental watch mode fell into place.

Dead features was always the core idea. Everything else — the SDK, the dashboard, the billing, the workspaces — exists to support the dead feature detection. The catalog-from-code approach only works if there's a reliable way to discover what's in the code. The CLI is that.

Ship less is underrated as a product strategy. Every feature you remove is maintenance you never have to do, bugs that can't exist, and cognitive load you save your users. Eventra is a tool for shipping less. I find that more interesting than another tool for shipping more.

Try it

If you have a TypeScript project and want to see what's dead:

# Install the SDK
npm install @eventra_dev/eventra-sdk

# Initialize the CLI config
npx @eventra_dev/eventra-cli init

# Scan and sync
npx @eventra_dev/eventra-cli sync

Free tier is 100k events/month, no credit card.

→ eventra.dev

The SDK and CLI are MIT-licensed:

Examples:
-github.com/and-1991/eventra-examples

Happy to answer questions in the comments — especially about the static analysis approach or the ingest pipeline design.

I Built Eventra in 6 Months (After My Day Job). Here's How.

Jura — Fri, 10 Apr 2026 19:17:25 +0000

Building Eventra After Work: A 6-Month Solo Developer Journey

For the past six months, I've been building Eventra after work.

I have a full-time job that pays the bills.
Eventra is something I build in the evenings and on weekends.

I didn’t start with a startup idea.
I didn’t start with validation.
I just wanted to build something properly.

Not a weekend project.
Not a demo.
Something real.

That eventually became Eventra — a feature analytics platform focused on understanding which features users actually use.

Why I Started Building Eventra

When you build products long enough, you accumulate features.

Some are used every day.
Some occasionally.
Some… never.

Over time, you lose visibility.

You don't know:

Which features matter
Which ones nobody uses
What can be removed

Analytics helps — but only partially.

Analytics shows what happened.
But it doesn't show what exists but never happens.

That idea stuck with me.

Building After Work

Building Eventra while working full-time wasn't easy.

Some days I wrote code for 8 hours at work, then another 2–3 hours at night.

Some weekends were spent debugging rollups instead of going outside.

Progress wasn't fast — but it was steady.

Over six months, Eventra slowly took shape.

Step 1 — Building the Core Platform

I started with the core platform:

Workspaces
Projects
Events
Feature adoption
Dead feature detection
Alerts
API keys
Operations dashboard

The goal was to build something complete — not just analytics, but a system focused on feature usage.

What the Dashboard Shows

The main dashboard gives a quick overview of product usage:

Total events
Unique users
Active features
Inactive features
Usage over time

This helps quickly understand whether your product is actually being used and how feature adoption changes over time.

Feature Tracking

Eventra tracks individual features and shows:

Total usage
Unique users
First used
Last used
Usage timeline

You can open any feature and see its detailed analytics and adoption patterns.

This makes it easier to understand which parts of your product matter.

Dead Feature Detection

One of the core ideas behind Eventra is detecting unused functionality.

Eventra automatically detects features that haven't been used recently and marks them as inactive.

For example:

Feature not used in 14 days
Feature used once but never again
Feature abandoned after release

This helps identify functionality that might be safe to remove.

Events Explorer

You can also inspect raw events.

This helps when debugging or understanding how users interact with your application.

You can see:

Event name
User
Timestamp
Usage patterns

This makes it easier to understand what users actually do.

Workspaces and Projects

Eventra supports:

Multiple workspaces
Multiple projects
Team members
Permissions

This allows you to organize analytics across different products.

API Keys and SDK Integration

Each project has API keys for event ingestion.

You can rotate keys, create multiple keys, and track usage.

This allows safe integration with SDKs and backend systems.

Operations Dashboard

I also built an internal operations dashboard.

It shows:

Ingest throughput
Buffer size
Rollup lag
Processing delay
System health

This helps monitor the analytics pipeline.

Interactive Demo

There's an interactive demo on the homepage:

https://eventra.dev

You can explore the UI, navigate between pages, and see how everything works.

Some data is intentionally masked to avoid exposing real information.

This makes it possible to explore the product without signing up.

Step 2 — The SDK

Then I built the SDK.

import { Eventra } from "@eventra_dev/eventra-sdk";

const tracker = new Eventra({
  apiKey: "YOUR_PROJECT_API_KEY",
});

tracker.track("feature_used", {
  userId: "user_123",
  properties: { feature: "dashboard" }
});