πŸš€ Vibe Coding Kit

Build Your Own Mixpanel-Like Analytics Platform

Everything you need to own your data and understand user behavior

✨ Why Analytics is Perfect for Vibe Coding

Analytics platforms sound complex, but they're actually one of the most achievable indie projects you can build. Here's why:

πŸ“Š Event Tracking is Well-Understood The patterns are simple: capture events, store them, query them. No ML, no bleeding-edge techβ€”just solid fundamentals.
πŸ”“ Open Source Options Are Mature PostHog, Plausible, Umami, and Jitsu prove you can build production-grade analytics. Learn from them, fork them, or build your own.
⚑ Modern Databases Handle Scale ClickHouse and TimescaleDB can ingest millions of events/day without breaking a sweat. Scaling is a solved problem.
πŸ” You Own Your Data No vendor lock-in, no sending customer data to third parties, no surprise pricing. Your analytics, your rules.

The Real Win: Your users get privacy-first analytics. You avoid GDPR headaches. Everyone wins.

πŸ› οΈ The Tech Stack

Here's what actually works at scale, minus the hype:

Ingestion

  • Next.js API Routes β€” Easy, serverless, built-in auth
  • Fastify β€” Lightweight, blazing fast, minimal overhead
  • Why: Simple HTTP endpoint that accepts JSON events

Queue

  • Upstash Redis β€” Serverless, no ops, geo-replicated
  • AWS SQS β€” Reliable, battle-tested, pay per million
  • Why: Buffer spikes, decouple ingestion from storage

Storage

  • ClickHouse β€” Built for analytics, billions of rows
  • TimescaleDB β€” PostgreSQL-based, easier setup
  • Why: Column-based storage = fast queries, cheap storage

Dashboard

  • Tremor + Recharts β€” Beautiful charts, React
  • Plotly β€” More advanced, heavier
  • Why: Real-time, responsive, looks like a real product

SDK

  • Custom JS Snippet β€” 2-3KB minified
  • Auto-captures page views, clicks, custom events
  • Why: No dependencies, works everywhere, own the experience

Hosting

  • Vercel/Railway β€” For the API
  • Render/Digital Ocean β€” For ClickHouse
  • Why: Simple, scalable, reasonable costs at any size

πŸ’¬ Copy-Paste Prompt for Cursor AI

Use this prompt to generate your analytics platform with Claude/Cursor:

You are building a Mixpanel-like analytics platform for indie developers.

REQUIREMENTS:
- Event Ingestion API: Accept POST /api/events with {userId, eventName, properties, timestamp}
- Queue Processing: Use Redis/SQS to buffer events before storage
- Database: Store events in ClickHouse (or TimescaleDB as fallback)
- JavaScript SDK: Auto-track pageviews, clicks, form submissions, custom events
- Dashboard: Real-time analytics with charts for:
  * Event counts over time (line chart)
  * Top events (bar chart)
  * Unique users per day (trend)
  * Funnels (multi-step conversion tracking)
  * Retention cohorts (day 1, day 7, day 30 retention)
  * User segmentation (filter by properties)
- API: GraphQL or REST endpoints for querying analytics
- Auth: Simple API key authentication
- Data Retention: Configurable, default 90 days

TECH STACK:
- Backend: Next.js API routes or Fastify
- Queue: Upstash Redis or AWS SQS
- Database: ClickHouse (primary) or TimescaleDB (fallback)
- Frontend: React + Tremor + Recharts
- SDK: Vanilla JS, ~2-3KB minified, no dependencies

ARCHITECTURE:
1. Client sends events via lightweight JS snippet
2. Events hit the ingestion API (/api/events)
3. API validates and pushes to Redis queue
4. Background worker pulls from queue, batches events
5. Batch insert into ClickHouse
6. Dashboard queries ClickHouse for real-time analytics
7. GraphQL/REST API serves data to frontend

FEATURES TO BUILD (Priority Order):
1. **Event Ingestion**
   - Accept events at high volume
   - Batch writes to database
   - Handle duplicate detection (idempotent)
   - Track event timestamp, userId, properties

2. **JavaScript SDK**
   - Auto-track pageviews (document.location)
   - Auto-track clicks on data-analytics-event elements
   - Custom event API: analytics.track('event_name', {prop: value})
   - Auto-batch and send every 5 seconds or when buffer hits 50 events
   - Persist in localStorage to handle offline

3. **Funnel Analysis**
   - Define a series of steps (e.g., signup β†’ verify_email β†’ first_purchase)
   - Track drop-off at each step
   - Show conversion rate % and absolute counts
   - Support date range filtering

4. **Retention Cohorts**
   - Cohort by signup date or any event
   - Track % of users active on day 1, 7, 14, 30
   - Visualize cohort retention curves
   - Compare cohorts over time

5. **User Segmentation**
   - Filter users by properties (country, plan, signup_source, etc.)
   - Save segments as reusable filters
   - Show segment size and retention
   - Analyze event patterns within segments

6. **Real-Time Dashboard**
   - Event counts with sparklines
   - Live user count (users seen in last 5 minutes)
   - Top events happening right now
   - System status (events/sec, queue depth)

FEATURES TO SKIP (for MVP):
- Predictive analytics, anomaly detection, ML models
- Custom cohort builder UI (use raw SQL)
- White-label / multi-tenant
- Advanced attribution
- Heatmaps / session recording

DATABASE SCHEMA:
```sql
CREATE TABLE events (
  event_id UUID,
  project_id String,
  user_id String,
  event_name String,
  properties JSON,
  timestamp DateTime,
  date Date,
  country String,
  device String
) ENGINE = MergeTree()
ORDER BY (project_id, user_id, timestamp)
PARTITION BY date;
```

CODE STYLE:
- TypeScript everywhere
- Zod for validation
- Clear error messages
- Logging for debugging
- Unit tests for core logic

PERFORMANCE:
- Ingest 10k events/sec minimum
- Query response <500ms for 90-day range
- Dashboard load in <2 seconds
- SDK injection time <50ms

Start with the event ingestion API and SDK. Then build the storage layer. Finally, add the dashboard and analysis features.

This should take 2-3 weeks for a solid MVP.

πŸ—οΈ Architecture Diagram

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ YOUR USERS' APPS β”‚ β”‚ (embedded analytics.js snippet) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ POST /api/events β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ INGESTION API LAYER β”‚ β”‚ (Next.js API routes or Fastify server) β”‚ β”‚ β€’ Validates event schema β”‚ β”‚ β€’ Deduplicates by event_id β”‚ β”‚ β€’ Pushes to queue (Redis/SQS) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ MESSAGE QUEUE β”‚ β”‚ (Upstash Redis or AWS SQS) β”‚ β”‚ β€’ Buffers events during traffic spikes β”‚ β”‚ β€’ Decouples ingestion from storage β”‚ β”‚ β€’ Durable, survives restarts β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ β–Ό β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ WORKER β”‚ β”‚ WORKER β”‚ β”‚ (consumes β”‚ β”‚ (parallel) β”‚ β”‚ queue) β”‚ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ ANALYTICS DATABASE LAYER β”‚ β”‚ (ClickHouse or TimescaleDB + PostgreSQL) β”‚ β”‚ β€’ Column-oriented storage β”‚ β”‚ β€’ Optimized for analytical queries β”‚ β”‚ β€’ Partitioned by date for performance β”‚ β”‚ β€’ Retention policies (auto-delete old data) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ β”‚ β–Ό β–Ό β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚Dashboardβ”‚ β”‚GraphQL β”‚ β”‚REST API β”‚ β”‚(React) β”‚ β”‚/REST API β”‚ β”‚(Node.js) β”‚ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜ β”‚ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ Real-Time Analytics β”‚ β”‚ - Funnels β”‚ β”‚ - Cohorts β”‚ β”‚ - Segments β”‚ β”‚ - Events β”‚ β”‚ - User profiles β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ KEY DATA FLOW: 1. Event sent from client (analytics.js) 2. API validates and queues 3. Worker batches events (50 events or 5 seconds) 4. Batch inserted into ClickHouse 5. Dashboard queries ClickHouse (with caching) 6. Results streamed to React UI in real-time

πŸ“… 3-Week Build Plan

A realistic roadmap to get from zero to a working analytics platform:

Week 1: Ingestion & Storage

  1. Day 1-2: Set up project, create API endpoint, validate events
  2. Day 2-3: Set up ClickHouse (or TimescaleDB) locally
  3. Day 3-4: Implement event insertion, batch logic
  4. Day 4-5: Add Redis queue for buffering
  5. Day 5: Load test β€” can it handle 1000 events/sec?

Done: Can ingest and store events at scale

Week 2: SDK & Dashboard

  1. Day 1-2: Build lightweight JS SDK (~2-3KB), auto-track pageviews
  2. Day 2-3: Test SDK in demo app, ensure it works cross-domain
  3. Day 3-4: Build basic dashboard (React + Tremor)
  4. Day 4: Add event count charts, top events
  5. Day 5: Real-time updates via WebSocket or polling

Done: Fully functional analytics dashboard

Week 3: Analysis Features

  1. Day 1-2: Implement funnel analysis (multi-step tracking)
  2. Day 2-3: Build retention cohort queries and visualizations
  3. Day 3-4: Add user segmentation (filter by properties)
  4. Day 4-5: Polish, test, deploy to production

Done: Full-featured analytics platform

πŸ’‘ Pro tip: Deploy to production after Week 1. Get real data. Use Week 2-3 to optimize based on actual usage patterns.

πŸ”“ Open Source to Fork & Learn From

These projects prove analytics is doable. Study them, learn from them, build your own take:

PostHog

The heavyweight: full-featured product analytics platform. Massive codebase but incredible reference.

github.com/PostHog/posthog

Python/Django + ClickHouse + React

Plausible

Privacy-first web analytics. Clean, focused, great UX. Smaller codebase, easier to understand.

github.com/plausible/analytics

Elixir + ClickHouse + React

Umami

Simple, self-hosted web analytics. Great for learning. Node.js-based, easier to modify.

github.com/umami-software/umami

Node.js + PostgreSQL + React

Jitsu

Customer data platform + analytics. Shows how to build complex data pipelines.

github.com/jitsucom/jitsu

Kotlin/Java + ClickHouse

Strategy: Start by running Umami locally. Understand how events flow. Then read Plausible's code for design patterns. Finally, study PostHog for advanced features. By day 3, you'll know exactly what to build.

πŸ“ˆ Scaling Considerations

Good news: analytics scales beautifully. Here's what to expect:

πŸš€ ClickHouse Performance

  • βœ“ 1M events/day: Commodity hardware ($30/mo)
  • βœ“ 100M events/day: Mid-range server ($200/mo)
  • βœ“ 1B+ events/day: Cluster with replication ($2k+/mo)

Queries stay fast (<500ms) because of column storage and partitioning.

πŸ’° Cost at Scale

  • βœ“ 10M events/mo: ~$150 (compute + storage)
  • βœ“ 1B events/mo: ~$1,500 (still < Mixpanel)
  • βœ“ 10B events/mo: ~$15,000 (but Mixpanel is $50k+)

You own the infra. No SaaS markup.

πŸ”„ Queue Sizing

  • βœ“ Redis: Buffer 100k+ events in memory, ~1GB/100M
  • βœ“ SQS: Cheaper for massive volume (billions)
  • βœ“ Workers: Run 2-4 workers per CPU core

Batch processing every 5 seconds = smooth, efficient writes.

πŸ“Š Optimization Tips

  • βœ“ Partition by date β€” Auto-prune old data
  • βœ“ Sample events at high volume β€” 1% sample β‰ˆ same insights
  • βœ“ Cache dashboard queries β€” Pre-aggregate common metrics
  • βœ“ Use ReplacingMergeTree β€” Handle duplicates elegantly
Reality Check: Even at 10B events/month, you're cheaper than Mixpanel or Segment. You own the data, control the UX, and scale without vendor games.

🎯 Why This Project Works

βœ… Achievable

No ML, no black magic. Straightforward event β†’ store β†’ query β†’ visualize pipeline. You can ship a solid MVP in 3 weeks.

βœ… Valuable

Every SaaS, every indie app, every startup needs analytics. You're solving a real problem, and people will pay for privacy-first solutions.

βœ… Defensible

Once you have users' data running through your platform, they're sticky. Great network effect.

βœ… Scalable

ClickHouse + Redis + Fastify can handle millions of events per second. You won't outgrow your stack.

πŸš€ Start Today

Step 1: Fork Umami or Plausible. Understand the codebase.

Step 2: Spin up a local ClickHouse instance. Ingest some fake events.

Step 3: Build your first query. Visualize it. Feel the magic.

By day 2, you'll have working analytics. By week 2, you'll have a product. By week 4, you'll have customers.