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.
Design: evidence first, assumptions labeled
Four case studies now carry a design process section: a proto persona, a journey map and a user flow, with the rest of a double diamond core set behind each one. They are built in a fixed order. First an evidence pass: who has actually used the thing, what they did, and what broke. Then the artifacts, with every line that rests on assumption rather than evidence marked (A), and the marks stay until research replaces them. No research, quotes or metrics are invented. Each image passes the same name and redaction checks as the page text before it ships.
The useful part is what the evidence did to the pages. Off the Shelf's outcome said the app lost because the household leaves in a rush; its one real trip showed it lost in the aisle, to a notes app, because the imported list was wrong, and the case study now says so. Foreground's page described daily use that had stopped, and its artifacts start from why. Gridledger's thesis gained capture context from my own field work. The Validator's artifacts are built for the handoff to the team taking it over.
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 a GitHub organisation the project did not own; 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 has since been reconciled against work that shipped ahead of it, so the two tell the same story: each date on it traces to a commit, a deploy or another dated record, and each change carries a comment naming its source.
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. The spec half now exists.
The Anomaly Upload Validator is an internal tool, so the build itself is not something I can show. Its documentation is: five specification documents, rendered as pages rather than offered as files to download. The product requirements, the user stories with their acceptance criteria, the data dictionary and the 72 test cases are the spec. The release notes are what shipped against it, across five versions.
The pair is the point, because the release notes record where the spec did not survive contact with reality. Real exports came back with Blade Side written as full descriptive names rather than the two-character codes the spec had assumed, and with Serial Number missing often enough that requiring it was wrong, so v1.2 demoted that field and corrected the required count from 19 to 18. A second dataset arrived with a different column structure and produced, in the document's own words, "widespread false Manual Review flags"; v2.1 detected the structure instead of assuming one. A formula that was right in principle was wrong in practice, because Excel reads a cell holding an empty string as not blank, so the same release swapped ISBLANK() for a LEN() guard. Two of the five versions ship with a "Known Issues at Release" list, which is the part a spec usually leaves out.
Two limits on that, stated rather than left to be noticed. The conversion tables are redacted out of those documents: they map values across vendor, platform and client schemas, that crosswalk is proprietary, and the pages mark where it was removed rather than quietly dropping it. And the validator case study carries no usage figure. What those documents demonstrate is a spec written, revised against evidence, and honest about what it left undone. What the tool saved is not shown, and will not be until there is a measurement worth publishing.
The board was held back until the backlog matched what shipped, because a board that does not reflect reality proves only that the tool is installed. It matches now, so it is shown rather than promised.
This page still claims only what is linked, quoted or shown above.