Case study

Logbook

A decision and tech-debt registry built around a single idea: reversibility, not a backlog label, is what should decide how much scrutiny a decision gets.

Role: Design and build, solo

Stack: Next.js, TypeScript, Zustand, Supabase, Vitest

Logbook's public homepage, with the pitch: most technical debt isn't tracked, it's just remembered by whoever took the shortcut

Why it exists

The problem this was built to solve, and the approach behind it.

Before · the problem

Most technical debt gets logged as a ticket, and tickets do not age well.

After · the approach

Logbook is modeled on the Architecture Decision Record format.

No distinction between a decision reversible in an afternoon and one load-bearing for two years

Marked reversible or one-way-door, so scrutiny matches what's actually at stake

Revisiting a decision means editing the row, and losing the reasoning that was there before

Context, decision, consequences, and alternatives captured on every entry, not overwritten

A deferred tradeoff just becomes debt, ranked the same as everything else

A deferred tradeoff carries a real review date instead of sitting in a backlog indefinitely

What it does

A public homepage paired with a full decision registry app
Log a decision with context, consequences, and alternatives, not just a title
Reversible or one-way-door classification drives a risk score, not just a due date
Deferred tradeoffs carry a real review date and surface as overdue
Every change (created, commented, resolved, superseded) is captured as an event, so each decision has a full activity timeline
Versioned state, so a schema change does not break existing data
Search, sort, a keyboard shortcut to create a decision, and toast feedback on actions

In the product

Swipe or click through a few screens from the working app.

The all-decisions view in Logbook, searchable and sortable by priority, type, status, and review date

The Logbook overview dashboard: active decisions, debt exposure, overdue reviews, and a breakdown by category and priority

The log-a-decision form in Logbook, capturing context, consequences, and alternatives considered, plus type and cost to undo

Architecture decisions

The calls that shaped the build, written the same way the product itself records them.

Domain logic, not UI logic

The decision model, overdue detection, risk scoring, and the supersession chain all live outside React, framework-free and deterministic. The rules that decide what counts as risk don't depend on how anything gets rendered.

Supersession, not editing

A registry that quietly loses history when someone changes their mind is not a registry. Revisiting a decision creates a new record linked to the old one instead of mutating it.

Risk scoring, not just a due date

Risk score combines cost-to-undo with an urgency multiplier that rises the longer a decision sits overdue, capped rather than open-ended, so the dashboard ranks what actually needs attention first.

Want something built with this kind of judgment?

A focused 30-minute call to scope the work and see if it is a fit. No pitch.