Get started
Building Eventra · Part 10 of 102 min read

What's next for Eventra: design partners and a focused set of channels

  • buildinpublic
  • saas
  • startup
  • product
1Conversationsengineering leads, PMs2Design partnerone real codebase3Priced pilota paying customer

Most of this series has covered engineering: what was built, what broke, and what I changed. This post covers the next phase of the project, which is about getting Eventra into real codebases.

Where the product stands

The product is complete enough to use today:

  • The CLI builds a feature catalog from the code (TypeScript, React, Vue, Svelte, Astro, Angular).
  • The SDK sends usage events from the browser, Node, Edge and serverless runtimes.
  • The dashboard classifies every feature as new, active, declining, dead or never seen, with unique users, custom date ranges and per-user activity.
  • A live read-only demo on the homepage shows all of it without a signup.
  • Free, Pro and Enterprise plans are live, and every plan includes the full dashboard.
FeaturesEvery feature in the catalog with its state and usage.Search features...AllActiveDecliningDeadNever seenFEATURESTATETOTAL USESUSERSLAST USEDcheckout_startedActive1,820214Sep 25, 2026classic_editor_openedDeclining37834Sep 25, 2026bulk_deleteDead339Sep 9, 2026export_to_notionNever seen00-
The Features page: every feature with its state, uses and unique users.

The roadmap sequences the next work on purpose. The enterprise phase (SSO, self-hosting, SLA, read replicas) comes after one question is answered with real use: does a team retire dead code because of what Eventra shows it?

The plan: three steps

The phase is called "Validate demand" on the roadmap:

  1. Customer discovery. Conversations with engineering leads and product managers about one specific situation: the last time they wanted to delete a feature and could not tell whether anyone used it.
  2. A design partner. One real, non-demo codebase running the full pipeline, with a team that retires dead code based on the results.
  3. A priced pilot. A paying customer, even at a small amount. A payment is the signal that counts.

How I approach distribution

My time is split between building and everything else, and building is where most of it goes. So I use a small number of channels and do each one properly instead of spreading thin:

  • dev.to: regular technical write-ups of real problems from the codebase. Each article starts from a problem a reader recognizes and goes deep into the solution.
  • This blog: the build log of the product, for people who want to follow how Eventra is made.
  • The live demo: the homepage lets anyone see the real dashboard in one click. It is the most direct answer to "what does this do".
  • Direct conversations: the discovery calls above.

Each of these keeps working after it is published: an article, a demo and a post stay online.

If you want to help

If you are an engineer or a product manager and you have ever hesitated before deleting a feature because you could not tell whether it was used, write to support@eventra.dev, or open the live demo first to see the product. A twenty-minute conversation about how your team decides is the most useful input I can get. If you want to try Eventra on a real codebase as a design partner, write to the same address.