pincushionA website feedback tool developers can act on.
Most website feedback tools are built for the person leaving the comment. A developer needs the opposite: enough context to find the element in the source and reproduce what the reviewer saw. Here is what to look for, and how Pincushion handles each point.
What a developer needs in every report
| Needed | Why it matters | In a Pincushion pin |
|---|---|---|
| Page URL | Reproduce on the right route and state | Captured at click time |
| CSS selector | Find the element in the source with a search | Captured |
| DOM snippet | See the markup the reviewer actually saw | Captured |
| Screenshot | Confirm the visual problem | Captured |
| Viewport size | Reproduce responsive bugs at the same width | Captured |
| Thread and status | Ask questions, see what is approved or done | Per pin |
Where the work happens
Reviewers pin the live page through the Chrome extension or an embeddable widget, so nothing about your app has to change. You read the pins where you already work. The Pincushion MCP server exposes them to your editor's agent, and the docs cover setup. Only approved pins are meant to be implemented, so unvetted opinions do not become tasks.
Closing the loop
When a fix ships, fix_and_resolve records the commit SHA, branch and PR URL on the pin. The reviewer sees what changed without asking you. For the agent side of this, read handing visual feedback to AI coding agents; for the underlying concept, what a visual feedback MCP server does.
What it is not
Pincushion is not an issue tracker or a QA governance suite. If you want a tracker, keep yours and use pins as the source of well-formed reports. See how Pincushion compares to other website feedback tools.
Start free
Pincushion's free tier covers one project with unlimited manual pins and 25 AI actions a month, and every new account starts with a 14-day full-Pro trial. Commenters are always free. See pricing for the details (checked 2026-10-28).