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:
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" }
});
The SDK supports:
- Batch sending
- Retry logic
- Browser / Node / Edge runtimes
- TypeScript-first API
This worked well — but something was missing.
The SDK only tracks events that actually happen.
Which meant I still couldn't detect:
- Features that exist but aren't used
- Dead UI
- Forgotten code
Step 3 — The CLI
That's when I built the CLI.
The CLI scans your codebase and finds all tracked events:
npx @eventra_dev/eventra-cli init
Then it:
- Scans your project
- Finds track() calls
- Detects wrapper components
- Saves configuration
Now Eventra can compare:
- Events in code
- Events actually triggered
And detect unused features.
That's when Eventra became a complete product.
The Hardest Parts
Each part had its own challenges:
Backend — rollup engine
Frontend — workspace/project architecture
CLI — AST parsing and wrapper detection
The CLI ended up being one of the hardest parts technically.
Current Status
After 6 months:
- Dashboard — production-ready
- SDK — stable
- CLI — early version (0.0.4)
I'm still building this solo, after work.
Pricing
I'm not trying to maximize revenue right now.
The goal is validation and feedback.
Try It
Website
https://eventra.dev
SDK
https://www.npmjs.com/package/@eventra_dev/eventra-sdk
CLI
https://www.npmjs.com/package/@eventra_dev/eventra-cli
GitHub
https://github.com/and-1991/eventra-sdk
https://github.com/and-1991/eventra-cli
Why I'm Sharing This
I'm not trying to sell anything.
I'm just building something useful after work.
If you're also building something on the side — I'd love to hear about it.
And if Eventra looks useful, I'd love your feedback.
Top comments (0)