Turn your GitHub activity into daily standups, weekly summaries, and a burnout signal — automatically.
DevPulse connects to your GitHub and turns your real commits, pull requests, and issues into AI-generated standup reports, weekly narratives, and a deterministic burnout score — with zero manual input. Unlike generic productivity tools that ask you to log your day, DevPulse reads your actual activity and derives everything from source: sign in with GitHub, select repos, hit sync, and your dashboard is live.
Live demo → devpulse.tanisheesh.in
- AI standup reports — Yesterday / Today / Blockers written from your previous day's commits and PRs. Paste directly into Slack.
- Burnout score — 0–100 signal based on late-night and weekend commits measured against your own 60-day baseline; timezone-aware, vacation-aware, fully auditable.
- Full commit analytics — Heatmap, coding hours, PR cycle time, code churn, and commit quality score — all from synced GitHub data.
- Goal tracking — Set weekly targets for commits, PRs, and issues. Get an AI check-in on where you stand.
- Monthly review — AI-generated performance paragraph grounded in real data, suitable for 1:1s or self-evaluations.
| Layer | Tech |
|---|---|
| Framework | Next.js 16 · App Router · TypeScript 6 · Turbopack |
| Auth | Auth.js v5 · GitHub OAuth |
| Database | Neon Postgres (serverless) · Prisma 7 |
| AI | Groq API · Llama 3.3 70B Versatile |
| Styling | Tailwind CSS v4 |
| Charts | Recharts |
| Infra | Vercel |
Why a deterministic burnout score instead of asking an AI to judge it? The score is computed from raw commit timestamps using a clamped linear scale against the user's own 60-day baseline — no model involved in the number itself. This makes every score auditable and traceable to specific commits, not a black-box model opinion.
Why Groq + Llama 3.3 70B instead of a hosted OpenAI or Anthropic model? Groq's inference speed and free-tier throughput fit the on-demand, per-user-click pattern well. The prompts send structured JSON (commit titles, PR titles, counts) — never raw diffs — so the model doesn't need deep code understanding, making a fast 70B model the right tradeoff.
Why AES-256-GCM for stored GitHub tokens?
The GitHub OAuth access token is the most sensitive credential in the system. It is encrypted with AES-256-GCM (random 12-byte IV per token) immediately after OAuth, and the plaintext copy the PrismaAdapter writes to the Account table is overwritten to null in the same transaction — so no plaintext token ever persists.
What would you do differently in v2?
Add nonce-based CSP headers instead of relying on Next.js hydration's unsafe-inline allowance, and add proper rate-limiting middleware rather than the current DB-query-based cooldown check on the sync route.
| Document | Description |
|---|---|
| PRD | Product requirements — goals, user stories, non-goals |
| Architecture | System design, data flow, component breakdown |
| Decisions | Every major technical decision and why |
| Setup | Local dev setup, env vars, deployment |
Tanish Poddar — tanisheesh.in · LinkedIn · GitHub