← All projects
Project

Feature Pulse

A multi-user, AI-powered dashboard where teams track multiple features and builds across products, with AI summaries and insights on every feature.

Live ↗GitHub ↗
MERN StackPythonAI

A feature-adoption and event-telemetry platform for product teams. Add one SDK call to your app, and FeatureTrack shows who used each feature, how often, and what broke — across every environment.

The problem

Teams ship features but rarely know whether anyone uses them. Analytics tools track page views, not features, and wiring up custom tracking for every release is slow. I wanted a tool where tracking a feature takes one line of code, and adoption shows up on a dashboard within seconds.

What I built

  • Lightweight SDK: a TypeScript SDK (@featuretrack/sdk) with a single track() call that takes an event name, a feature key and optional properties
  • Event pipeline: ingests events with idempotent retries, so duplicates aren't counted, and warns when an event's schema drifts from earlier events
  • Feature adoption tracking: builds adoption curves per feature from the feature key on each event
  • Live event stream: tail production events in real time, filtered by user, feature flag or environment
  • Analytics dashboard: KPI cards (total events, active users, adoption, error rate), events over time, top events and ranked feature adoption, with date-range filters and export
  • Environments and API keys: separate Production, Staging and Development environments, with keys scoped to each so development data never reaches production
  • Multi-user workspaces: projects, team members with roles, and audit logs of who changed what
  • Developer tools: API key management, an API explorer, webhooks and quickstart docs

Tech stack

  • Frontend: [Next.js / React], TypeScript, Tailwind CSS
  • Backend: [Node.js / Next.js API routes]
  • Database: [MongoDB / PostgreSQL]
  • SDK: TypeScript, published as an npm package

Challenges

  • Counting events accurately: retries can send the same event twice, so I made ingestion idempotent and deduplicated on an event ID.
  • Keeping data clean as apps change: property types are inferred on first use and enforced afterwards, with warnings when a schema drifts.
  • Isolating environments: API keys are tied to one environment, so test traffic can't pollute production metrics.

What I learned

How to design a developer-facing SDK, build a reliable event-ingestion pipeline, and present large amounts of usage data as a dashboard people can act on.

Feature Pulse — Swarup