Kiroku

What it is

Kiroku is a developer-focused timeline system. The basic question is simple: what did I actually do today?

It is not a note-taking app. It pulls activity from the places where engineering work already leaves traces, then tries to rebuild the shape of the day from those traces.

Problem it solves

Developers lose track of time because work is split across commits, PRs, reviews, meetings, debugging, and context switching. A commit says something changed, but it rarely explains how long the work took, what interrupted it, or what happened between two useful commits.

Kiroku tries to make that invisible work easier to inspect. It aggregates signals, reconstructs a timeline, and gives a daily or weekly view of where time actually went.

How it works

The system fetches GitHub activity, contribution patterns, and project events, then normalizes them into a common activity model. From there it maps events into timeline blocks: coding sessions, PR work, review windows, quiet gaps, and possible context switches.

The timeline is intentionally approximate. The goal is not perfect surveillance. The goal is to turn scattered developer activity into something useful enough to reason about.

How I built it

Kiroku is built with Next.js App Router, TypeScript, Supabase, PostgreSQL, and GitHub API integration. The backend handles fetching, normalization, persistence, and aggregation. The frontend focuses on daily and weekly views that make the reconstructed timeline readable without pretending the data is cleaner than it is.

Most of the interesting work is in the data shaping layer: taking raw GitHub events, commits, PR activity, and contribution data, then converting them into blocks that feel closer to actual work sessions.

Interesting challenges

GitHub data is useful, but incomplete. A commit might represent ten minutes of work or three hours of debugging. A PR update might be the result of focused implementation, review feedback, or cleanup after a meeting.

That made the core tradeoff accuracy versus usability. Kiroku has to handle ambiguous data, avoid overclaiming, and still produce a timeline that helps. I had to think about developer activity as data: what signals are trustworthy, what should be inferred carefully, and where the UI should admit uncertainty.

Why I built it

I built Kiroku because I kept ending days with a vague sense that I had been busy, but no clear picture of where the time went. The work was real, but the record of it was fragmented.

It is not a polished SaaS yet. It is an evolving system built from a real problem I had, used by me first, and shaped around the uncomfortable truth that developer work leaves messy signals.