Cashbook — Monthly Development Report

A note on what gets counted

The metrics below describe code shipped by the development team: changes merged, tickets completed, work units delivered. They don't capture the strategic work that surrounds and drives that output — product specs, designs, prototypes, code review, architecture decisions, and stakeholder alignment. Aidan Scott (founder, fractional CTO, designer, PM) operates in that mode: he authored 470 of the 759 tickets that closed in this engagement (62%). Inside each month below you'll see a separate "Strategic & product input" line that shows how much of the dev work came from scope he defined, and how many new tickets he wrote for future delivery. That's the closest read we have on his contribution — the dev metrics alone systematically understate it.

Cadence vs. spend

Bars show changes shipped per month (merged code changes that landed in the live codebase). The line shows the retainer cost for that month. Use this to see how much output came out for what went in.

New features Bug fixes Improvements Internal & infra

How to read this report

Changes shipped
The number of completed code changes (pull requests) merged into the live codebase that month. A reasonable proxy for raw activity.
Tickets completed
Discrete units of work tracked in Linear that closed within the month. May not match changes shipped 1:1 — some tickets close without code (research, planning); some changes land outside a ticket (small fixes).
Work units
A rough size estimate the team puts on every ticket before work begins, on a scale of 1–5. Think of it like t-shirt sizing for tasks: a 1-unit ticket is something a developer can finish in roughly an hour (tweak a setting, fix a small bug); a 3-unit ticket is a half-day's work (a new form, a feature that touches a few screens); a 5-unit ticket is a chunky multi-day job (a brand-new system or anything that needs investigation first). Adding them all up gives you a feel for the weight of the month, not just the headcount of tickets — twenty 1-unit tickets is a very different month from ten 5-unit ones, even though both look similar on a count alone.
PRDs
Product Requirements Documents. Each is a logical feature group (e.g. PRD-6: GST Returns). Tickets are grouped under them so you can see what feature drove the month.
Strategic & product input
A read on Aidan's fractional CTO / designer / PM contribution that doesn't show up in the dev metrics. Most tickets in Linear are written by Aidan and worked on by the dev team — he defines the scope (PRDs, tickets, designs, prototypes, architecture) and they execute. The numbers here count tickets he authored that closed this month, plus the new tickets he wrote this month for the team to pick up next.