DEV Community: Jura

Every feature in our catalog had at least one user. It was the same user every time - our own scanner.

Jura — Fri, 25 Sep 2026 18:32:03 +0000

Picture the cleanup meeting. The dead-features report says export_to_notion was used once, by one person, three weeks ago, and never again. So the conversation goes where it always goes with a feature like that: somebody tried it, it didn't work for them, and they never came back. Maybe the flow is confusing. Maybe it's buried. Someone takes an action item to look at the onboarding for it.

Now suppose the truth is different: nobody ever used it. Not once. The button sits behind a feature flag that never got turned on in production, and the "one user" is a bookkeeping record the analytics tool itself wrote when it discovered the feature in the code.

Those two stories need completely different fixes. "Used once and abandoned" is a product question - why did people leave? "Never fired at all" is an engineering question - is this code even reachable, and is the tracking call actually wired up? Sending a feature to the wrong one of those meetings wastes a week and still leaves the real problem in place. That second scenario isn't hypothetical for us: Eventra's dead-feature detector was sending every never-used feature to the wrong meeting, by design, and it took an embarrassingly long time to see it.

How a catalog tool learns that a feature exists

Eventra has two halves. A runtime SDK sends events when people actually use things. A CLI statically scans the codebase with the TypeScript compiler API and finds every track("...") call - including ones behind wrappers, re-exports and framework templates - so the tool knows what features exist, not just which ones happen to fire. That second half is the whole point: you can't notice that a feature is never used if the only features you know about are the ones that get used.

eventra send uploads that catalog. On the server, each name that isn't known yet has to be recorded somewhere, and the obvious "somewhere" was the pipeline that already existed. So the CLI endpoint pushed every newly discovered name through the normal ingest path as a synthetic event:

await this.ingest.trackBatch(workspaceId, projectId, toCreate.map((name) => ({
  idempotencyKey: randomUUID(),
  name,
  userId: '__scan__',
  properties: {
    _internal: 'scan',
    cli: { name: cli?.name, version: cli?.version, runtime: cli?.runtime },
  },
  timestamp: new Date().toISOString(),
})));

The billing code knew about these. It skipped anything carrying that sentinel user id and marker property, so nobody was ever charged for their own catalog. That's the part that got tested, because a billing bug is the kind that gets a support ticket.

Nothing else knew. The rollup job that turns raw events into per-feature numbers treated a synthetic event exactly like a real one. So every feature the CLI discovered got:

totalUses = 1 and uniqueUsers = 1
firstUsed and lastUsed set to the moment someone ran eventra send
a phantom row in the per-user tables under that sentinel user id, which also bumped the project's unique-user count and every adoption percentage
two property stats from the marker property and the metadata blob, because the rollup stringifies property values and the nested object became [object Object]

Then time did the rest. For the first 7 days, the feature got a "New" badge. Until day 14 it was "Active". After that it was "Dead" - "had usage before, nothing since", which is precisely the wrong story. A feature that was never used could not show up as never used, because by construction it had been used once.

The worst detail: our own homepage listed "Never seen - in your code, never reached the platform" as one of the lifecycle states. The product couldn't produce it. And the internal changelog from three weeks earlier had a line that said, more or less, "known limitation, not fixed here". We had written it down and moved on, because it didn't break anything visible. It just made the most useful signal the product has into a slightly wrong version of a different signal.

Fix #1: one definition of "synthetic", used everywhere

The first real problem was that "is this a CLI bookkeeping event?" was answered in exactly one place, inline in the billing code. Every other consumer had to know to ask, and none of them did. So the check moved into one small module that everything imports:

export const CLI_SYNTHETIC_USER_ID = '__scan__';
export const CLI_SYNTHETIC_MARKER = 'scan';

export function isCliSyntheticEvent(e: {
  userId?: string | null;
  properties?: Record<string, unknown> | null;
}): boolean {
  return (
    e.userId === CLI_SYNTHETIC_USER_ID &&
    e.properties?._internal === CLI_SYNTHETIC_MARKER
  );
}

Billing, the rollup and the CLI endpoint all use it now. The raw events feed and the "top users" query read the raw table directly in SQL, so they needed an SQL version of the same predicate, and that is where the one genuinely sharp edge in this whole fix was hiding.

The obvious SQL is NOT ("userId" = '__scan__' AND properties->>'_internal' = 'scan'). It looks right and it's wrong. SQL uses three-valued logic: for an anonymous event, "userId" is NULL, so that first comparison isn't false, it's NULL. If that event also has no properties, the other side is NULL too, NULL AND NULL is NULL, NOT NULL is still NULL, and a WHERE clause treats NULL as "no". Every real anonymous event without properties would have silently vanished from the events feed. Not the synthetic ones - the real ones.

export const NOT_CLI_SYNTHETIC_SQL = Prisma.sql`
  NOT COALESCE(
    "userId" = ${CLI_SYNTHETIC_USER_ID}
      AND properties->>'_internal' = ${CLI_SYNTHETIC_MARKER},
    false
  )
`;

The COALESCE(..., false) says "if you can't tell, it isn't synthetic", which is the only safe default. The test for it asserts the SQL actually contains NOT COALESCE, because this is exactly the kind of line someone "simplifies" six months later.

Fix #2: register the feature, don't use it

The rollup now splits synthetic events out before any usage math happens. They still matter - they're how the tool learns the feature exists - but all they produce is an aggregate row with nothing in it:

INSERT INTO "FeatureAggregate"
  ("projectId","name","totalUses","uniqueUsers","firstUsed","lastUsed","createdAt","updatedAt")
VALUES (...)  -- 0, 0, NULL, NULL for every registered name
ON CONFLICT ("projectId","name") DO NOTHING

DO NOTHING matters: if the feature already has real usage, or was already registered by an earlier scan, the registration changes nothing. And lastUsed IS NULL is now the "never seen" state. It needed one schema change, making lastUsed nullable, and it needed surprisingly little else. Every existing "active / dead / new / all" query already filtered on totalUses > 0, so registered-but-unused features dropped out of all of them without touching a single query. A new endpoint and a new dashboard page list them on their own, which is where they belonged in the first place.

The part I was nervous about was the transition: what happens when a never-seen feature finally gets its first real event? The normal upsert for real usage does this:

"firstUsed" = LEAST(COALESCE("FeatureAggregate"."firstUsed", EXCLUDED."firstUsed"), EXCLUDED."firstUsed"),
"lastUsed"  = GREATEST("FeatureAggregate"."lastUsed", EXCLUDED."lastUsed")

In Postgres, GREATEST and LEAST ignore NULL arguments, so GREATEST(NULL, '2026-09-25 10:00') is just the timestamp. The first real event fills both dates in with no special case. I didn't want to trust that from memory, so it got run against a real database before anything else was built on it.

Fix #3: repairing data you can't simply recompute

Fixing the code only protects the next scan. Every project that had ever run eventra send already had phantom uses, a phantom user, and wrong dates sitting in its aggregate tables. The tempting fix is "replay everything from raw events". Two things make that a bad idea:

Raw events are kept for 12 months. The aggregates live forever. Replaying from raw would quietly delete real history older than a year.
Replaying means resetting the rollup's cursor, and the rollup runs every minute in production. Race that and you double-count everything.

So the repair is a single migration that subtracts exactly what the synthetic events added, and nothing else. Its outline:

BEGIN, then take the same Postgres advisory lock the rollup takes on every tick (pg_advisory_xact_lock), so no rollup tick can run in the middle of the repair.
Collect the synthetic raw events the rollup has already counted, meaning the ones at or before its cursor. Anything after the cursor is left for the new rollup code to handle correctly.
Subtract their uses from the daily, hourly and lifetime tables, and from the two synthetic property values.
Remove the sentinel user's rows from every per-user table, decrementing the matching unique-user counts first. Those rows survive past raw retention, so this part covers every age.
Recompute firstUsed and lastUsed for each affected feature from what's left. For the first and last day with real usage, use the most precise source that still exists: a raw event if there is one, else the hourly bucket, else the start of the day. No usage left means totalUses = 0, both dates NULL: never seen.
COMMIT.

Three details came out of running the migration against a scratch database seeded with deliberately awkward data - through the real prisma migrate deploy, the same way production applies it - instead of just reading it.

Timestamps without a time zone. firstUsed and lastUsed are timestamp, not timestamptz, holding UTC by convention. My candidate values came from timestamptz columns, and Postgres converts one to the other using the session's time zone. On a server whose session isn't UTC, every recomputed date would have been shifted by hours. Every candidate now goes through an explicit AT TIME ZONE 'UTC'. The check that proves it: run the migration twice from scratch, once with the database's TimeZone set to UTC and once to Asia/Tokyo, and diff the results. They're byte-identical.

The lock you take by accident. ALTER TABLE ... DROP NOT NULL is a metadata-only change and runs instantly. But it takes an ACCESS EXCLUSIVE lock that is held until the transaction commits, and inside a transaction that also scans a large raw-events table, that means the dashboard can't read aggregates for the whole scan. The ALTER moved from the first line of the migration to just before the final update, the only statement that needs the column to be nullable.

Failure has to mean nothing happened. One more run with the raw table deliberately renamed away, so a statement in the middle fails. The migration errors, and afterwards the column is still NOT NULL and every number is unchanged. One transaction, nothing half-applied.

The awkward seed data is what made these checks worth anything. It had a feature that only the CLI ever touched, a feature the CLI registered that real users adopted later, a real feature whose users set their own property called cli (it must survive untouched), anonymous events, a synthetic event newer than the rollup cursor, and a feature whose raw events were already past retention. After the migration, each one ended up exactly where it should. The last one also documents the one honest limitation: a synthetic event older than 12 months can't be subtracted, because the raw row it came from no longer exists. In practice that's one use per feature, and only for projects that ran the CLI more than a year ago.

What "done" actually meant

Unit tests pin the code down, but they can't prove much about a bug like this one, because every mock is written by the same person with the same mental model as the code - which is exactly how the original bug survived. The final check was the real pipeline instead: raw events written exactly the way the ingest path writes them, processed by the real rollup running in the real API, read through the real dashboard in a headless browser.

A CLI-only feature came out as 0 uses, 0 users and no dates, and appeared on the Never seen page. A feature the CLI registered and a real user then touched came out with exactly one use and one user, and none of the marker-property junk. The sentinel user appeared in no user table anywhere.

The rest of what shipped with it

Fixing "never seen" made it obvious how much else the dashboard was hiding, so it shipped alongside:

Declining features. Still used, but at half or less of the previous period, measured on the same window as the dead threshold. It deliberately excludes today, since a half-finished day compared against full ones makes everything look like it's falling. It also skips features with too little history to have a baseline.
Exact unique users over time. Counted with COUNT(DISTINCT) from per-day user rows. Summing the stored per-feature counts would count someone who used three features three times.
Custom date ranges, per-user pages, and drill-downs everywhere. Every number on the overview links to the feature, user or event behind it.

Try it

If you want to see the never-seen state on real-looking data: eventra.dev has a "Try live demo" link on the homepage, no signup, straight into a workspace with dead, declining and never-seen features in it. And if your own product has an "internal" or "system" user anywhere in its analytics, it's worth running one query to check how many of your numbers it's quietly part of.

A correct validation rule almost broke a request our existing customers had been making for months

Jura — Thu, 10 Sep 2026 12:46:51 +0000

You've shipped this exact change before, probably more than once: a feature that's the obvious mirror image of one you already have. You already flag features as "dead" after N days of no events - customers ask for the opposite, a "new" flag for features that just started getting used. Same table, same kind of threshold field, same UI slot. It reads like an afternoon of work, because the hard part - detecting a feature's usage lifecycle from raw events - is already solved. You're just adding the other half of a pair.

That's exactly the case that's dangerous, because "the other half of a pair" is where code quietly assumes the pair will always relate to each other the way you're imagining right now, in the twenty minutes you're spending on this. We added the mirror image of an existing feature, wrote what looked like an obviously correct validation rule for it, and that rule would have rejected a request our existing customers had already been making successfully for months - a request that had nothing to do with the new field at all.

The feature: nothing surprising

Eventra flags a feature "dead" when it's had no events for N days - 14 by default, configurable per project. We added "new": a feature is "new" for N days after its first event - 7 by default, same per-project override. Same table, same kind of field, same kind of badge next to it in the UI. The actual detection logic is maybe fifteen lines: swap lastUsed for firstUsed, flip a comparison. This part shipped exactly as boring as it sounds.

The two thresholds have to stay in a specific relationship, though: a feature can't reasonably be "new" (fired for the first time recently) and "dead" (hasn't fired in a while) at the same moment, which becomes possible the instant someone configures the new-threshold larger than the dead-threshold. So the project-settings endpoint got a check:

if (nextNewThreshold > nextDeadThreshold) {
  throw new BadRequestException(
    'newFeatureThresholdDays must be less than or equal to deadFeatureThresholdDays',
  );
}

Read it on its own and there's nothing wrong with it. It's the correct invariant, stated directly, rejected with a clear message. It's the kind of line that sails through review because reviewing it means checking "is this logically true," and it is.

The part that isn't visible from the rule itself

Here's what the rule doesn't show you: the dead-threshold field already existed, already had months of live customer configurations, and its allowed minimum is 1 day. The new-threshold field is brand new, and every existing project got it from a migration with a default of 7 days - a default nobody chose, stamped onto every account retroactively, including accounts that will never open the settings page and notice it exists.

Now replay an entirely ordinary support scenario. A customer who set their dead-feature threshold to 5 days three months ago - because their product ships fast and features go stale quickly - opens settings today and tries to lower it to 3 days. Same field they've edited before, same kind of change they've made before. The request now fails with a 400 about newFeatureThresholdDays - a field this customer has never seen, sitting at a default value they never chose, silently in conflict with the one field they're actually trying to change.

That's not a hypothetical edge case you'd need bad luck to hit. It's the default outcome of "add a symmetric field with a fixed default, then validate it against a pre-existing field whose live values already span a wider range than the new field's default." It passes every unit test that only exercises the new field's own valid range. It passes code review, because the validation logic is genuinely correct. It only surfaces the first time a real customer, with a low-enough pre-existing value in the other field, touches that other field - which for a field that's been configurable for months, is not a matter of if.

The fix: tell the two cases apart

The rule was conflating "the user asked for an invalid new-threshold" with "the new-threshold just happens to be sitting in the way of something else they asked for." Those need different responses:

if (nextNewThreshold > nextDeadThreshold) {
  if (dto.newFeatureThresholdDays !== undefined) {
    // they explicitly asked for a value that doesn't fit - say so
    throw new BadRequestException(
      'newFeatureThresholdDays must be less than or equal to deadFeatureThresholdDays',
    );
  }
  // they only touched deadFeatureThresholdDays - the new field was never
  // part of their request, so adjust it instead of rejecting theirs
  nextNewThreshold = nextDeadThreshold;
}

If someone explicitly sets an invalid newFeatureThresholdDays, they still get told exactly why, immediately. If they never mentioned it and it just happens to sit above whatever they're lowering deadFeatureThresholdDays to, it gets quietly pulled down to match instead - the request that always worked keeps working, and the invariant still holds afterward either way.

That covers every request from here on. It doesn't cover the rows already sitting in the database with the same conflict, from before the check existed - a customer at dead=5 already has new=7 sitting there right now, invalid, untouched, waiting for the day they edit either field and get a result they didn't ask for. So the migration that added the field got a follow-up: a plain backfill, applied once, capping the new field wherever it already exceeded the old one.

UPDATE "Project"
SET "newFeatureThresholdDays" = "deadFeatureThresholdDays"
WHERE "newFeatureThresholdDays" > "deadFeatureThresholdDays";

Without it, the code-level fix only protects the next edit. The invariant would still be false, quietly, for every account that happens to already be in that state - correct from here forward is not the same claim as correct right now, and a migration is the only place you get to make the second claim true retroactively.

What actually catches this

Nothing about this bug shows up by testing the new field in isolation. A fresh test suite's fixtures are exactly as consistent as whoever wrote them - the fixtures for a brand-new field are never going to include "an old field, from a real account, configured to a value from before this field existed," because you have to go looking for that scenario on purpose. The question that surfaces it isn't "does my new validation work for valid inputs to the new field," it's "for every row that already exists, is my new invariant already true, or could it already be violated before anyone touches anything" - and that second question only gets asked if you go look at what's actually sitting in the table, not just at what the migration's default value claims.

The concrete version of that, for a schema change specifically: after writing the migration, don't just check that it applies. Check what the data looks like the moment after it applies, for every row that was there before it ran, against whatever new rule you're about to enforce on top of it. If any existing row could already fail that rule, the rule needs a plan for those rows before it ships, not just for the next request that happens to touch them.

Try it

The "new" feature status is live on eventra.dev now - features get flagged "new" for their first 7 days, configurable per project, right next to the existing dead-feature detection. If you want to see it on real data: the homepage has a "Try live demo" link, no signup, straight into a populated workspace.

We put a real, live dashboard on our homepage with no signup wall. Here's how it survives strangers.

Jura — Tue, 01 Sep 2026 11:51:25 +0000

You land on a SaaS product's homepage. It looks good. You want to see the actual dashboard before you decide whether five more minutes of your life are worth a signup form. There's no way to. "Book a demo." "Start free trial" (email required, sometimes a card). A carousel of static screenshots that were true eighteen months ago. So you close the tab, and the product loses you before you ever saw the product.

We didn't want to be that tab-close. So we put a real, live, populated workspace behind a "Try live demo" button on the homepage - no email, no account, one click, straight into the actual dashboard with actual-looking data: usage charts, dead-feature detection, an events feed. Not screenshots. The real app.

The problem with that idea is the second half of the sentence: the real app, open to anyone. A dashboard is normally only as trustworthy as its access control, and we were about to hand out a session to whoever clicked a button, pointed at data other visitors are looking at too. Here's what actually had to be true before that button could ship.

"Hide the buttons" is not a security model

The lazy version of a public demo is a normal account with the delete/edit buttons hidden in the UI. It's also worthless as protection, because nothing stops a visitor from opening devtools, finding the real API call behind that hidden button, and firing it directly. UI-level restrictions are a UX feature, not an access-control boundary - they describe what a well-behaved client does, not what the server allows.

So the read-only guarantee for our demo account isn't a frontend concern at all. It's a single interceptor sitting in front of every request the backend handles, checked after auth and before any handler runs:

const SAFE_METHODS = new Set(['GET', 'HEAD', 'OPTIONS']);

@Injectable()
export class DemoReadOnlyInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    const req = context.switchToHttp().getRequest<AppRequest>();

    if (req.user?.isDemoAccount && !SAFE_METHODS.has(req.method)) {
      throw new ForbiddenException('The demo account is read-only.');
    }

    return next.handle();
  }
}

It's registered globally, once, next to the app's other cross-cutting interceptor. It doesn't know or care what the request was trying to do - create a project, delete a workspace, rotate an API key, invite a teammate. If the session belongs to the demo account and the method isn't GET/HEAD/OPTIONS, it's rejected before it reaches the controller. That's the whole surface. Every mutation endpoint in the app - workspaces, projects, invites, API keys, dashboard layout, even the admin routes - is covered by one check, not by remembering to add a guard to each one individually. The alternative (annotate every mutating endpoint by hand) is exactly the kind of thing that's correct on the day you write it and silently wrong the first time someone adds a new endpoint and forgets.

isDemoAccount itself is about as small as a security check gets:

export function isDemoAccount(email?: string): boolean {
  if (!email) return false;
  return email === process.env.DEMO_ACCOUNT_EMAIL;
}

One env var, one comparison, computed once per request in the auth guard and stamped onto req.user. No table to keep in sync, no role to accidentally grant to the wrong person later.

The gap that wasn't in the interceptor - it was next to it

Here's the failure mode that actually worried us once the read-only guard existed: what if the demo account somehow also ended up with platform-admin rights? Those are two completely independent booleans, computed from two completely independent env vars (DEMO_ACCOUNT_EMAIL, PLATFORM_ADMIN_EMAIL), by two completely independent checks. Nothing links them - which is fine, until someone misconfigures one operator's environment and sets both to the same address. The read-only interceptor only blocks mutations. It says nothing about reads, and platform-admin routes are gated purely by isPlatformAdmin, not by isDemoAccount. A misconfiguration like that would hand a public, no-login-required visitor read access to internal operator tooling - workspace-wide billing internals, every customer's account list, whatever else "admin" means in a growing app.

That's not a bug you find by testing the happy path. It's a bug you find by asking "what has to be independently true for this to be safe, and is any of it actually coupled to anything else." The fix is one line, in the same place both flags get computed:

isPlatformAdmin: !demoAccount && isPlatformAdmin(session.user.email)

Demo unconditionally wins. Even if an operator someday points both env vars at the same address, the account that resolves as "demo" can never also resolve as "platform admin" - it's not a policy documented in a runbook that says "don't do that," it's a line of code that makes the mistake structurally impossible instead of merely inadvisable.

A demo that doesn't visibly rot

A demo account that never gets new data is a different kind of broken - it's harder to notice, but "last used: 4 months ago" on every feature is its own way of telling a visitor the product is dead. So the demo workspace reseeds itself every hour, on a cron, wiping and regenerating its own analytics tables (aggregates, daily/hourly stats, the raw event feed - synthesized in memory as one internally-consistent event stream, not generated table by table) so "last used" always looks like today, whatever time zone the visitor is in.

The part worth calling out isn't the cron - it's what happens if two requests hit it at once, which will happen the moment you run more than one instance of the API:

const { rows } = await lockClient.query(
  'SELECT pg_try_advisory_lock($1)',
  [LOCK_ID],
);

if (!rows[0]?.pg_try_advisory_lock) return;

A Postgres session-level advisory lock, held for the entire multi-transaction refresh. If a second instance's cron fires while the first is still mid-reseed, it just checks the lock, sees it's held, and returns immediately - no queueing, no duplicate writes, no two processes racing to regenerate the same rows. And if the reseed itself throws partway through, it's caught and logged, never rethrown - a failed tick just leaves last hour's data in place instead of leaving the demo workspace half-rewritten, and the next tick tries again.

What "done" required before this shipped

None of the above shipped on the strength of "looks right in a code review." Before we called it done:

Ran the actual seed script twice in a row against a local database and confirmed it doesn't duplicate the workspace, the projects, or double-count the current month's usage - a reseed job that isn't idempotent turns "every hour" into "growing forever."
Hit the real endpoints with a manually issued demo session cookie: GET /api/v1/auth/me (200 - reads work), POST /api/v1/workspaces (403 - mutation blocked), POST on the event-ingestion path (403 - can't be used to inject arbitrary events into the shared dataset either), GET on the analytics endpoints (200, real numbers back).
Wrote a dedicated collision test: set the demo-account env var and the platform-admin env var to the same address on purpose, and asserted the resulting session still comes back isPlatformAdmin: false. Not just "the normal case works" - the specific misconfiguration scenario, provoked deliberately.

The demo account also can't be used to bootstrap a live API key and start pushing real events into the shared workspace - there's deliberately no ProjectApiKey row created for the demo project during seeding, so there's no key for a visitor to find and copy. That one's a narrower guarantee than the interceptor (it's "we never created the door," not "the door is locked"), which is worth being honest about rather than overstating: the day a demo project would need a live key issued for some other reason, that assumption needs revisiting, not just re-trusting.

Try it

If you want to see what any of this looks like from the visitor's side rather than the request-log side: eventra.dev has a "Try live demo" link on the homepage and the sign-in page. One click, no account, into a populated workspace that's never more than an hour stale. Poke at it, try to break something - it's read-only by construction, not by convention, so go ahead.

Your feature-usage scanner doesn't know Vue, Svelte, or Astro exist. Here's how we fixed that without touching its core.

Jura — Fri, 21 Aug 2026 09:32:28 +0000

If a static analyzer only walks .ts/.tsx/.js/.jsx, every other file type isn't scanned badly - it's not scanned at all. A .vue component, a .svelte widget, an .astro page: none of them exist to the tool. Not "low confidence." Not "partial support." Invisible, the same way an empty search result looks identical whether there's genuinely nothing to find or the search just never looked in the right place.

That's exactly the gap Eventra's CLI had. It scans a codebase and tells you which tracked features are actually used - the whole pitch is "stop guessing which code is dead." Except if your team ships a Vue admin panel, a Svelte checkout widget, and an Astro marketing site around the same core app (which, if you've worked on more than one team, you've probably seen - nobody plans a multi-framework stack, it just accretes), the CLI would silently skip all three, report a clean scan, and never mention that it hadn't actually looked. The exact failure mode the product exists to prevent, happening inside the product itself.

We'd already closed this gap once, for Vue. This month we closed it for Svelte and Astro too, and the interesting part isn't the frameworks - it's that adding two more meant touching exactly zero lines of the CLI's core analysis engine.

The trick: don't teach the core anything

The CLI's core is a TypeScript-compiler-API engine: it builds a real program, walks real ASTs, resolves real symbols across files, and figures out which .track("event_name") calls are statically reachable. It is, deliberately, framework-agnostic - it doesn't know what Vue is, and it shouldn't have to.

So instead of teaching the core about .vue/.svelte/.astro, each framework gets a small, separate plugin whose only job is a translation: take the framework file, hand back one virtual TypeScript module. A Vue Checkout.vue becomes Checkout.vue.ts. A Svelte Cart.svelte becomes Cart.svelte.ts. The core never sees the original file - it sees TypeScript, because by the time it looks, that's what's actually there.

export interface CliPluginTransformResult {
  readonly modules: readonly { readonly path: string; readonly content: string }[];
}

That's most of the contract. A plugin declares which globs it wants (**/*.svelte), a match() to claim files, and a transform() that returns virtual modules. The core registers the glob, calls transform() on matching files, and feeds the result into the exact same incremental TypeScript program every .ts file goes through. No if (isVueFile) branch anywhere in the resolver, the propagation engine, or the wrapper detector. They don't know these files were ever anything but TypeScript.

The part that has to be a real compiler, not a regex

The first version of the Vue plugin - before this month - parsed .vue files with two regexes: one to grab <script> content, one to grab event="..." attributes out of <template>. It worked on every fixture, because every fixture was written to be exactly what that regex expected. It fell over on real code: dynamic bindings vanished silently, HTML comments got matched as if they were live markup, and <script> + <script setup> got concatenated with zero understanding of how Vue actually merges them.

The fix - and the standard we held Svelte and Astro to from the start - is to parse with the framework's own real compiler. Not a library that looks similar. The actual thing:

Vue: @vue/compiler-sfc, the same package Vite and Nuxt build on.
Svelte: svelte/compiler's parse(), in its documented legacy-AST mode (modern: false) - stable, tooling-oriented, and it gives you IfBlock/EachBlock/AwaitBlock as real distinct node types instead of text to pattern-match.
Astro: @astrojs/compiler, the WASM parser the Astro toolchain itself uses, which hands back a typed AST with element/component/expression nodes.

Three different compilers means three different AST shapes, and the differences turned out to matter more than expected. Svelte's legacy <script context="module"> node has no attributes field at all - recovering lang="ts" meant regex-matching the raw opening-tag text, not asking the AST for it. Astro's attribute nodes carry a kind (quoted / expression / shorthand / template-literal / …) and hand you the already-extracted expression source directly; Svelte makes you slice the original source string yourself using a MustacheTag's expression.start/.end offsets. And Astro's JSX shorthand - <Button {event} />, sugar for event={event} - leaves the attribute's .value empty for that specific kind, so the plugin has to notice the shorthand case and substitute the attribute name back in as the expression. None of that is guessable from documentation; it's the kind of thing you only find by parsing real snippets and printing the actual AST.

One convention, three parsers

Eventra's templates use a plain attribute, event="checkout.cta", to mark a tracked interaction directly in markup - no wrapper function needed for the simple case. It needed to mean the same thing in all three frameworks, expressed in whatever each one's own binding syntax actually is:

<!-- Vue -->
<button event="checkout.cta" />
<button :event="computedName" />

<!-- Svelte -->
<button event="checkout.cta" />
<button event={computedName} />

<!-- Astro -->
<button event="checkout.cta" />
<button event={computedName} />

Literal or dynamic, each plugin turns every one of these into a synthetic function call inside the virtual module - __eventra_svelte_template_event__("checkout.cta") for a literal, __eventra_svelte_template_event__(computedName) for a dynamic one, unquoted. Because it's a real call sitting in the same module scope as the actual <script>/frontmatter, a dynamic binding that happens to reference a real constant defined a few lines up gets resolved through precisely the same symbol-resolution path a plain tracker.track(someVariable) would use in any .ts file. If it can't be resolved - say, an {#each} loop variable - it's reported as a dynamic occurrence instead of silently vanishing, which was the entire bug that made the first Vue regex implementation dangerous.

The plugin declares this callee as a staticSink - { id, callee, eventNameArgumentIndex } - and the core converts that into its own internal sink detector. The plugin never imports anything from the CLI. The CLI never imports anything framework-specific. They meet in the middle through a plain data contract.

Trusting a plugin without trusting arbitrary code

eventra.json lists which plugins to load, and it's a file that gets committed to git - which means it's PR-editable by anyone who can open a pull request. If the loader did import(anyStringFromThatFile), a one-line JSON edit in a PR would be arbitrary code execution on every machine that ever runs eventra sync. The fix already existed for the Vue plugin and needed zero changes to cover the two new ones: only packages matching @eventra_dev/cli-plugin-* - an npm scope only the maintainers can publish to - are ever dynamically imported. Anything else gets skipped with a warning. Adding Svelte and Astro meant the allowlist regex, written generically the first time, just worked; the only thing that proved it was a test asserting cli-plugin-svelte matched it, written before the Svelte plugin itself existed.

Proving it actually works, not just that the unit tests pass

Unit tests for a plugin are cheap to fool - you write the fixture, you write the assertion, and if you got the mental model wrong in the same way twice, they both pass anyway. So after the plugins were built and green, we did the thing a real npm consumer would do: packed all four packages (SDK, CLI, and both new plugins) into actual .tgz tarballs with npm pack, installed them into a throwaway project exactly the way npm install would from the registry, and ran the real compiled eventra binary against a .svelte and an .astro fixture, each with one direct SDK call and one template event="..." binding.

{
  "events": [
    "astro.checkout.cta",
    "astro.checkout.started",
    "svelte.checkout.cta",
    "svelte.checkout.started"
  ]
}

Four events in, four events out, through the actual dynamic-import loading path, not a mocked one. That's the difference between "the code that implements the feature is correct" and "the feature works when a stranger installs it," and it's cheap enough to do that there's no excuse not to.

What "done" actually required

Each plugin ended up with roughly twenty tests and a hard 100% statement/branch/function/line coverage gate, and the coverage gate is what surfaced most of the interesting edge cases, not the other way around. A branch that never gets hit is either a real gap or a genuinely impossible case - and it's worth knowing which before shipping either way. A few turned out to be the second kind: svelte/compiler's attribute grammar guarantees a single-value attribute is either plain text or one expression, never a third thing, so the "neither" branch in that check is unreachable by construction, not untested by neglect. Those got a one-line comment explaining why, instead of a fabricated test pretending to exercise something the parser's own grammar rules out. The rest - a boolean-shorthand event attribute with no value, an interpolated event="a-{b}" that's neither a clean literal nor a clean expression, a context="module" script block that's present but empty - were real gaps, and each one is a case someone's actual codebase would eventually hit.

Try it

pnpm add -D @eventra_dev/cli-plugin-svelte @eventra_dev/eventra-cli
# or
pnpm add -D @eventra_dev/cli-plugin-astro @eventra_dev/eventra-cli

{
  "plugins": ["@eventra_dev/cli-plugin-svelte", "@eventra_dev/cli-plugin-astro"]
}

Same config shape as the Vue plugin, and you can list all three at once if your codebase actually is that mixed. Svelte plugin on npm · Astro plugin on npm · Vue plugin on npm · docs.

Angular's next. If your own tool has a hard-coded list of "supported" things, it's worth asking whether the boundary is actually load-bearing, or whether it's just the first three cases someone happened to write down.

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" }
});