Roadmap

What we're building, in order

This is a working plan, not a promise — phases are sequenced by dependency (a stable, secure backend before more surface area, more surface area before enterprise commitments), and dates aren't fixed. Status reflects what's actually shipped and verified in production today.

Phase 0

Foundation

Done

Core ingest, rollup, billing, and analytics pipeline, plus the CLI and SDK clients that feed it — all audited end to end.

CLI 2.0.7

Semantic analysis, wrapper propagation, watch mode

Done

SDK 2.0.4

Circuit breaker, leader election, idempotency

Done

Backend

Ingest, rollup, billing, auth guards

Done

Dashboard

Dead feature detection, ops dashboard

Done

Backend audit

7 critical bugs found and fixed

Done

Dashboard audit

13 findings fixed and verified in production

Done

Phase 1

Stability & Security

Done

Hardening the ingest and auth surface before scaling traffic — most of this phase is already live.

Bind API keys to a host

Origin/Referer allowlist per key, opt-in via ENFORCE_API_KEY_HOST_BINDING

Done

X-Forwarded-For spoofing fix

Done

Soft-deleted sessions invalidated

Done

Rolling session refresh

Done

Proxy body-size limit & timeout

Done

CI/CD gates

Lint + build required before deploy

Done

Backend-driven filters

Search/date-range filters on events, features, dead features

Done

Overview widget layout

Drag-and-drop, per-project, blocks + widgets independently reorderable/hideable

Done

Phase 2

Plugins & Framework Support

In progress

Extending static analysis beyond a single parser so the CLI understands how features are actually used across frameworks.

Plugin kernel

Preprocessor/sink-detector registry, external plugin contract, trusted-scope plugin loading

Done

Vue plugin 1.0.3

Real compiler-based parsing (script setup, dynamic bindings, Nuxt auto-import compatible)

Done

Svelte plugin 1.0.1

Real compiler-based parsing (script + context=module, dynamic bindings)

Done

Astro plugin 1.0.1

Real compiler-based parsing (frontmatter, dynamic bindings, JSX-expression templates)

Done

Angular plugin

Planned

Demo account

Seeded, read-only account for product demonstrations

Done

Dashboard redesign

Deeper per-screen detail (richer widgets, drill-down views) and new pages beyond today's high-level KPI overview

Planned

Phase 3

Product Analytics

Planned

Moving from "is this feature used" to "how is it used" — funnels, retention, alerting, and richer segmentation.

Funnels

Planned

Alerts

Planned

Retention

Cohort analysis

Planned

Custom metrics

Companies, custom fields

Planned

Integrations

Slack, Jira, Linear

Planned

Phase 4

Validate Demand

Planned

Everything through Phase 3 is what makes the product functionally comparable to existing usage-analytics tools. Before spending more engineering time on Phase 5's enterprise surface, the actual open question - will anyone pay for this - needs a real answer instead of another feature.

Customer discovery

Structured conversations with engineering leads/PMs who'd plausibly use dead-feature detection, run before any further build-out

Planned

Design partner

One real (non-demo) codebase running the full pipeline end to end, with an actual team retiring dead code because of it

Planned

Priced pilot

Someone paying real money, even a small amount, as the actual signal - interest and "cool idea" feedback don't count

Planned

Phase 5

Enterprise & Growth

Future

The scale and compliance surface for larger customers - further out, and dependent on real demand.

Multi-instance rate limiting

Redis-backed rate limiter and email-verification attempt limiter

Done

Multi-instance queues

Redis-backed billing queue, and rollup's property-stat carry-over moved from an in-process field to a durable table

Done

SSO / SAML / OIDC

Future

Self-hosted / on-premise

Future

SLA

Uptime guarantees

Future

Read replicas for analytics

Future

Phase 6

Feature Management

Future

The SDK already sits inside customer code and observes every tracked feature; this phase turns that one-way observation channel into a two-way one, so the dashboard can act on what it sees - not just report it. This is a bigger step than a typical toggle service: it puts the SDK in a position to change production behavior in real time, so it's gated on Phase 3's analytics/alerting maturity (to know reliably what's actually dead or erroring) and on Phase 5's trust surface (SSO, audit, SLA) before customers should extend that much control to a vendor. Speculative and demand-dependent - no committed timeline.

Bi-directional SDK channel

SDK can receive signed commands from the backend, not just emit events

Future

Feature flag API

`isEnabled()`-style gate in the SDK, with manual on/off control from the dashboard

Future

Auto-kill on dead/error detection

closes the loop with Phase 3 alerting: a feature flagged dead or erroring past a threshold can be disabled at runtime without a deploy

Future

Safe-mode guarantees

fail open to the last-known-good state on network loss, staged/percentage rollout, full audit log of every remote toggle

Future

Human-in-the-loop override

approval/rollback workflow for auto-kill decisions, since a server-driven runtime kill-switch is a new class of risk, not just a new feature

Future

Phase 7

Multi-Language Support

Future

The SDK and CLI are JS/TS-only today. Shipping an SDK in another language is the easy half — a thin client for batching, retries, and delivery, same shape as the existing SDK. The CLI's static detection is the hard half: it's built directly on the TypeScript compiler API (semantic AST walking, wrapper propagation, type-aware resolution), which doesn't carry over to another language's compiler or parser — each one is effectively a new analysis engine, not a port. The two are tracked separately below so a language can ship SDK-only (manual tracking, no auto-detection) well before it gets CLI parity. Speculative and demand-dependent — no committed timeline.

Python SDK

Future

Go SDK

Future

Java / Kotlin SDK

JVM backends and Android

Future

Static analysis parity

a dedicated static analyzer per language (not the SDK) for auto dead-feature detection outside JS/TS; a materially larger effort than any single SDK port

Future

Have input?

This roadmap is shaped by real usage

If a phase above is blocking you from adopting Eventra, or you need something that isn't listed, tell us - sequencing can change.

hello@eventra.dev