There was never a plan to build an "annotation tool." The prototypes were static HTML exports pushed to Vercel for the team to look at, and the only real problem was this: how does everyone leave feedback on them together?
A few off-the-shelf options came first. Vercel's built-in team comments needed a Pro upgrade. Embedding the prototype in a doc and using its comment feature was another route. Or drop in a third-party feedback widget — one line of script and you get a floating feedback button. That last one won, mostly because it was the least work, and it was running in minutes.
Then came actually using it. The flow was: open the tool, take a screenshot, write the note, close the tool. Reviewing a single page meant doing that round trip over and over. Leaving feedback hadn't gotten any easier — it had just moved somewhere else.
That question changed the direction. Not "plug in an existing feedback tool" anymore, but build an annotation layer that lives on the page: point at something, write about it, keep going, never leave. Several people writing, one person reading it all — which meant a backend to sync it.
The first version of a note was just a coordinate — the x/y of wherever you clicked. That turned out not to be enough. If these notes were eventually going to an AI coding assistant, what it needs to know is which element to change, not which pixel on the page. Coordinates can't carry that. So notes became element selections instead, automatically capturing the CSS selector, the element's text, and the structure around it.
Which raised the next problem. All this annotation logic was a script embedded in each prototype — sharing it with the rest of the team would mean pasting the script in and redeploying every time anything changed. Better idea: make it a standalone browser extension, keep the notes in a list on the right side of the page, and let clicking one jump to its element.
Being an extension raised something more practical still: if this gets handed to other people, does every local update mean repackaging and redistributing it by hand? That question turned directly into the reason to publish on the Chrome Web Store — once it's listed, updates push themselves.
Plenty went wrong along the way. Magic-link login broke for a while. A domain looked almost identical to an unrelated project's, and it took an embarrassing amount of debugging to notice the address was simply wrong. The first store submission declared permissions too broadly and got pushed into stricter review — it only passed after narrowing them to "granted when the user clicks." None of that is the point of this write-up, but all of it actually happened.
Looking back, the thing being solved is still the thing from the very beginning: how a team annotates a prototype together, and how that feedback becomes a change someone can actually make. The path just bent a few times — embedded script to standalone extension, coordinates to element selection, hand-delivered builds to automatic store updates. Every bend came from running into something specific, not from planning ahead.