Process · Every stage links to the work
The lifecycle, shown in the work rather than in a diagram.
Method is easy to assert and hard to prove. Each stage below points at the exact section of a build where that decision got made, so you can check it instead of taking my word for it.
Discovery: start with the person, not the feature
Every build here started from watching someone do something badly supported, not from a feature idea looking for a user. The FleetServ work opens on the user and the problem before it mentions software at all. Off the Shelf is the clearest case: its feature set was derived from real shopping lists across four iterations, so each capability traces back to an observed behaviour rather than an assumption. Gridledger began from a problem I kept meeting across five years of wind and solar asset data.
Prioritization: the cut is the decision
Any roadmap can list what is being built. The useful record is what got dropped and why, because that is where the tradeoff is visible. FleetServ documents what I prioritized and what I cut. Gridledger has its own section on what I cut from the thesis.
The clearest evidence is not a document at all. Foreground is a WSJF prioritization engine, and it manages its own roadmap as a groomed backlog. It is a prioritization method shipped as a working product and independently audited.
Judgment: decide, and be able to defend it
Most product decisions get made without enough information. What matters is whether you can say why you chose, and stand behind it later. FleetServ carries a judgment call on data I would stand behind, written up with the reasoning intact rather than smoothed over after the fact.
Sequencing: what would ship first, and why that order
A thesis is cheap until it is ordered. The Gridledger case study ends on what I would build first, which forces the argument to commit to a first slice instead of describing a finished platform.
Measurement: choose the question before the number
Success criteria written after launch are decoration. FleetServ states how I will know it is working as part of the case study, not as a retrospective. Gridledger says plainly that the site measures whether the argument lands.
This site is instrumented the same way. The metrics page documents a seven-event taxonomy where every event is paired with the question it answers, leads with what is deliberately not tracked, and includes a section on what the numbers cannot answer. It is cookieless and anonymous by choice.
Honesty: say what is not true yet
The hardest part of this discipline is retracting a claim once it stops holding. Two examples on this site, both deliberate.
Gridledger carries a section titled what is true today, and what is not. Its open-source licence, adapters and API are design commitments, not shipped facts, and the page says so. The concept site originally stated them in the present tense and pointed four buttons at an empty GitHub organisation; that copy was rewritten and those buttons repointed. It is why the card reads Concept rather than Live.
Off the Shelf previously claimed daily use. That claim was retracted when it stopped being demonstrable, and the card now reads "Four iterations, not yet adopted." The case study carries the adoption diagnosis instead of a number. No usage metric will be added to it unless there is a real one.
Backlog and specs: the ticket carries the reasoning
The work above was tracked in writing, in the case studies themselves, before it was tracked in a tool. The Jira project exists and is being reconciled against work that shipped ahead of the board, so the two tell the same story.
A ticket is where a decision goes to survive the conversation that produced it. Two from this site's own backlog, both closed or parked on evidence rather than on preference.
Apply StatiCrypt encryption to the gated page.
The original decision had reasoning attached: StatiCrypt encrypts the static file bytes, while an auth layer gates an app's interface but leaves the underlying HTML fetchable on a site with no backend. On static hosting, only the first of those actually protects the content.
The ticket closed anyway. Checking the full history before building it showed the pipeline had never been built at all, and that the project's own instructions file and the gated page itself had both claimed the variant was in git history. It never was. The close records that, so the false claim does not resurface the next time someone reads those files.
The page it was written for ships as a plain email request instead, noindex at both the meta tag and the response header.
Revisit the registrar decision after DNS cutover.
The domain's registration must stay active; letting it lapse is the one irreversible way to lose it. Everything else is optional, so the ticket lists the options and the checks rather than a plan: whether the domain was a standalone purchase or came bundled with a hosting plan, since canceling the plan can forfeit a bundled domain at renewal; the 60-day transfer locks that apply after registration and after a registrant contact change; and a hard sequencing rule that no transfer starts until the DNS cutover is confirmed working.
It is still open. A ticket that names its own preconditions is more useful open than a decision made early and revisited under pressure.
Neither of those is a board, and neither is a spec. Two additions are still planned here once they reflect reality rather than intent:
- The board. Epics, stories and their movement across a real delivery, shown once the backlog matches what shipped. A board with nothing in progress proves only that the tool is installed.
- Specs against outcomes. A written spec shown next to what actually shipped, with what changed and why. A spec on its own proves a document was written; a spec next to its outcome proves the spec survived contact with reality, or shows honestly where it did not.
Until then, this page claims only what is linked or quoted above.