Figma's comment system is built around a canvas. When your team ships the real product and iterates on the deployed thing, that canvas is gone — and so is the feedback loop you built around it. This is the gap most design-engineer teams hit silently.
What Figma comments actually depend on
Figma comments work because every comment is pinned to coordinates on a static frame. The frame doesn't change unless you change it. The comment knows where it lives because the canvas is frozen in time.
Your deployed app is none of those things. It has:
- Dynamic state — the button your reviewer pinned might not even be visible in the same state next session
- Responsive layouts — a comment placed at desktop coordinates is meaningless on mobile
- Moving DOM — element positions change as content loads, CSS shifts, or you ship a new version
- No frame — the live site has no "current version" a comment can attach to
This isn't a gap Figma will fill. It's a different problem in a different place.
Figma comments are anchored to a canvas. Your deployed app doesn't have one.
The moment the gap appears
For teams who design by building — prompting an agent, shipping something, then iterating on the deployed product — this gap shows up the first time someone who isn't the builder needs to give feedback. A client. A teammate doing crit. A PM with an opinion on the copy.
They're looking at the live site. You want their input on the live site. But the only tools they know how to use are Figma (which has no connection to what's live) and Slack (which turns every note into a screenshot with a red circle).
So they send the screenshot. You decode it. You write a prompt to your agent. The agent asks a clarifying question because the screenshot doesn't say which element, which page, which viewport, or which interaction state. You spend ten minutes reconstructing context that should have been captured automatically.
What teams reach for, and where each falls short
1. Keep commenting in Figma anyway
If the deployed app closely mirrors the Figma file, this can work for a while. But "closely mirrors" rarely stays true. The moment the live product diverges from the mockup — and it will — Figma comments are talking about something that no longer exists. Reviewers end up commenting on a stale canvas while the real problems are on the live site.
2. Screenshots annotated in Figma or Loom
Some teams screenshot the deployed app, paste it into Figma, and comment there. Better than raw screenshots in Slack, but it inherits most of the same problems: annotations are pixel-coordinates, not element anchors; context (viewport, page state, DOM) is lost; there's no thread attached to the thing you're actually shipping.
3. Vercel / Netlify preview comments
Preview deploy toolbars are genuinely useful for pre-merge review. They let reviewers comment on a build before it goes to production. The limits: reviewers need accounts on your hosting platform, the comments live on the preview (not the production site), and the output is a comment for a human to read — not a work item a coding agent can pick up and implement.
4. Bug-reporting tools (BugHerd, Marker.io, Userback)
These tools were built for QA and client sign-off: capture a visual bug, turn it into a ticket, track it on a board. They're solid at that job. The mismatch: design crit isn't bug reporting. You're not filing a defect, you're running a review — and the output going into a Kanban column is the wrong destination if you build with a coding agent.
5. Just use Slack and deal with it
The honest default. Zero setup, universally understood. The cost is entirely in translation time — every screenshot is a manual reconstruction job — and it compounds with each reviewer and each iteration cycle. A workable tax on small teams doing occasional reviews; a real drag on teams shipping fast and iterating in short loops.
What the alternative actually needs to do
Whatever replaces Figma comments for the deployed app needs to solve the things Figma comments solved well — while working in the new context:
| What Figma comments did well | What the deployed-app equivalent needs |
|---|---|
| Anchored to a specific element (not pixels) | Anchor by CSS selector + page URL — survives reloads and responsive layouts |
| Zero setup for reviewers — anyone in the Figma file could comment | Zero setup for reviewers — clients and PMs won't install your dev toolchain |
| Threaded, attached to the thing being discussed | Thread stays on the pin, not scattered across a Slack channel |
| Builder sees context: what frame, what state, what viewport | Builder (or agent) sees: selector, DOM snippet, screenshot, viewport, page URL, project context |
| Comments resolved when the change ships | Pin resolved in a specific commit and PR, optionally verified on the deployed site |
The fifth point is the one Figma never quite delivered — "was this actually fixed?" is a follow-up conversation. On a live product, you can close that loop automatically.
How Pincushion fills this gap
Pincushion is built for exactly this moment — when the feedback session happens on the deployed product, not a canvas, and the people reviewing aren't opening an IDE.
- A reviewer installs nothing. They use a browser extension you share once, or they click a link. They click anything on your deployed site and type a note. Reviewers are free and unlimited.
- The pin captures what Figma never could. CSS selector, DOM snippet, screenshot, viewport dimensions, and the full thread — bundled as an agent-ready work packet from the start.
-
Your coding agent reads pins via MCP. One call to
implement_approved_pinsin Cursor, Claude Code, Codex, or Windsurf pulls the full context. The agent doesn't need to ask what was meant — it has the element, the page state, and the thread. - The loop closes. When your agent resolves the pin, it attaches the branch, commit, and PR. The deploy hook links the production URL. Pincushion AI can re-check the fix and write the verdict back to the pin — so reviewers see "Fixed in PR #47, deployed to production, verified."
The workflow is the same one you had in Figma — pin, discuss, fix, close — but on the thing that actually ships.
Figma is still the right tool — for Figma work
This isn't an argument against Figma. For early exploration, component design, and sharing design decisions with engineers, Figma comments do their job well. The point is narrower: once you're iterating on the deployed product, the feedback loop needs to live there too — not in a file that's a step removed from the real thing.
Some teams run both in parallel: Figma for early-stage work, Pincushion for crit sessions on the live app. That's a reasonable split. The goal is just that no feedback lives in a screenshot in Slack.
I made Pincushion — it lets your team drop pins on the live app, and your AI coding agent (Cursor, Claude Code, Codex) picks them up as implementation-ready work packets. Free for reviewers. Setup takes 2 minutes.
Top comments (0)