Case Study
ProofKit
A reviewer clicks the thing that is wrong. It becomes a numbered ticket, anchored to that element, and stays open until the person who raised it says the fix landed.
02The One Idea
Every tool between a reviewer and the person who can fix something loses part of the report. The loss is different in each one, and it is never the part the sender noticed they were dropping.
03The Outcome
- 310Findings raised across 44 pageson the Shriram Financial Services site, in three days
- 100%Fixed within another three days
- 280Releases in two weeks
04The Proof
A pin is only worth anything if it still points at the right thing after the page has been edited, which is the whole reason the ticket exists. So a pin stores three independent signals, and they are tried in order: the first that still matches carries it. Change the page and watch which one does the work.
The page is as it was when the finding was raised.
- 01
The XPath
MatchesWhere the element sat in the document when the finding was raised. Exact while the structure above it holds, and the first thing an inserted block breaks.
- 02
The Text Fingerprint
MatchesWhat the element said. It survives the element being moved anywhere in the document, and it is the signal that fails the moment the copy is the thing that changed.
- 03
The Relative Position
MatchesWhere the element sat against the ones around it. The loosest of the three, and the last asked, because it is the one most easily satisfied by the wrong element.
The PinResolved
Nothing here guesses. A pin either resolves and says which signal carried it, or it reports itself orphaned. It never quietly points at the wrong thing, because a ticket pointing at the wrong element is worse than a ticket pointing at nothing.
05The Work
06In Depth
The rest of it, if you want it. Nothing above depends on opening any of these.
The BriefEvery tool between the person who notices a problem and the person who can fix it drops part of the report.
A content team proposed tracking website copy changes in a shared spreadsheet. Every tool between a reviewer and the person who can fix something loses part of it: a spreadsheet loses where, a screenshot loses what changed, an email thread loses whether it was ever done.
The MoveThe finding is raised from the page it is wrong on, by clicking the thing that is wrong.
Every tool between a reviewer and the person who can fix something loses part of the report. The loss is different in each one, and it is never the part the sender noticed they were dropping.
So the finding is raised from the page it is wrong on, by clicking the thing that is wrong. It becomes a numbered ticket anchored to that element, carrying a screenshot, routed to a team, and it is not closed until the person who raised it confirms the fix shipped.
| The Tool | What It Loses |
|---|---|
| A shared spreadsheet | Where. A row of text, and no way back to the element it describes |
| A screenshot | What changed. It can show the problem and never the fix |
| An email thread | Whether it was ever done |
The SpineRaising, routing, and the states a finding moves through before anyone can call it done.
Raising a Finding
From the page it is wrong on, on your own site or on anyone else's.
- Hold a modifier and click the element itself. No page reference to type, no screenshot to attach.
- A composer on the element, carrying the change type.
- A draft tray, so a pass over a page is one submission rather than forty interruptions.
- A screenshot travels with the ticket, so the report shows what the reporter saw.
- A Chrome extension for sites that are not yours and cannot carry the overlay.
The Pin
- Three signals stored per finding: an XPath, a text fingerprint and a relative position.
- Tried in order on every later visit. The first that still matches carries the pin.
- None matching is an orphan, and the ticket says so.
- It never quietly points at the wrong thing.
The Ticket's Life
- Numbered, so it can be referred to in a room where nobody has the screen open.
- Routed to a team rather than to a person, so it survives whoever is on leave.
- A status machine from raised through to confirmed.
- Only the person who raised it can close it, once they have seen the fix shipped.
Seeing the Work
- A builder dashboard: every ticket across every project.
- A team board split into inbound and outbound work.
- A visibility matrix, so who sees whose work is a setting rather than a convention.
- An audit log.
Under the HoodTwo Workers kept deliberately apart, so a bad site deploy cannot take the API down with it.
Conceived on a Friday, when the content team proposed tracking copy changes in a shared spreadsheet. The base was built over that Saturday and Sunday from a single markdown spec, and it was usable by Monday morning. It kept being developed and scaled from there, in the open, as it was used and as bugs were found and fixed. Written end to end in Claude Code with valuable open and private MCPs: roughly 24,000 lines across the Worker, the shared core and the extension, and 280 releases over two weeks. One Cloudflare Worker, one D1 database, one KV namespace and a Durable Object for real-time fan-out, with a framework-neutral core rendering all three surfaces. No framework, no build step for the app itself, no runtime dependencies. Fourteen migrations, each one a decision argued in the file before it runs, and tests named as claims rather than as descriptions, so the suite reads as the specification.
The Worker | One Cloudflare Worker, one D1 database, one KV namespace |
|---|---|
The Durable Object | Real-time fan-out |
The core | Framework neutral, and renders all three surfaces |
The extension | Chrome, for raising findings on a site that is not yours |
One core, three surfaces
The overlay on your own site, the extension on somebody else's, and the dashboard are the same core rendered three ways rather than three implementations of the same idea. A change to what a finding is happens once.
No framework, no build step, no runtime dependencies
For the app itself. It is what let the thing be usable on the Monday after the Friday it was proposed, and it is why an extension and a web app can share a core without a bundler standing between them.
Fourteen migrations, each one argued before it runs
The decision is written in the migration file above the statements that carry it out, so the reason a column exists is in the same place as the column.
Tests named as claims rather than as descriptions
The suite reads as the specification. A test called "a pin whose element was deleted reports itself orphaned" is a sentence about the product; one called "test anchor resolution 3" is a sentence about the test file.
The CraftA pin records four ways back to its element, and reports itself orphaned rather than pointing at the wrong one.
The report is raised where the problem is
Not in a tracker beside it. Everything a spreadsheet row would have made somebody type, the page already knows: the URL, the element, the copy, and what it looked like at the moment somebody objected to it.
The person who raised it decides when it is done
A ticket closed by the person who fixed it records that the work happened. A ticket closed by the person who raised it records that the problem went away, and those are not the same claim.
An orphan is a result, not a failure
A pin that cannot find its element says so and stays on the board. Silently dropping it loses the finding; silently rebinding it to the nearest candidate loses the reader's trust in every other pin on the page.
It replaced the tools it was measured against
Its one live deployment so far is the Shriram Financial Services site, where five teams ran on it, Content, Product, SEO, Marketing and Business, and it replaced Jira and the Excel trackers that had been doing the job between them.
It never quietly points at the wrong thing.