DEV Community: MatttDamon

You skipped Figma and just built it. Your team still has notes.

MatttDamon — Wed, 24 Jun 2026 23:47:34 +0000

More teams are starting from a prompt now, not a canvas. You describe the thing, an agent builds it, you ship it. It's faster. But the place your team used to leave feedback, Figma comments, was attached to the canvas you just skipped. So the notes have nowhere to land.

What's actually happening to Figma

Figma went public in the summer of 2025. A year on, the stock sits well below where it opened and a long way off its first-month highs (mid-2026). Revenue is still growing. This isn't a "Figma is dying" post.

The slide tracks one specific worry: tools that let you generate a working UI without opening a canvas at all. Anthropic shipped Claude Design in April 2026. Cursor has design features. The bet the market is making is that fewer projects will start in a design file. That's the same shift you're living if you build straight from a prompt.

Here's the part nobody priced in. The canvas was never just where the design lived. It was where the conversation lived. Skip the canvas and you don't just lose a mockup step, you lose the room everyone gave feedback in.

Figma comments weren't about pixels. They were the one place your whole team could point at something and say "this is off."

Skipping the canvas skips the comments too

Think about what a Figma comment actually did. A teammate, a client, a PM with an opinion on the copy, none of them opened an IDE. They opened a file, clicked the thing, and typed. The builder saw exactly which element, in which frame, with the thread right there.

When the work moves straight to a deployed app, that whole loop has no home. The reviewer is looking at the live site. You want their input on the live site. But the tools they know are Figma (no connection to what shipped) and Slack (every note becomes a screenshot with a red circle).

So they send the screenshot. You decode it. You write a prompt to your agent. The agent asks which element, which page, which viewport, because the screenshot doesn't say. You spend ten minutes rebuilding context that should've been captured the moment they clicked.

Where the notes go now, and why each is rough

Comment back in Figma anyway. Works right up until the built app stops matching the file, which is fast. After that your reviewers are commenting on a canvas that no longer describes what's live.

Screenshots in Slack. The honest default. Zero setup, everyone gets it. The cost is all in translation, and it compounds with every reviewer and every iteration.

Preview deploy toolbars. Vercel and Netlify preview comments are genuinely good for pre-merge review. The catch: reviewers need an account on your host, the comments live on the preview not production, and the output is a note for a human to read, not a work item your agent can pick up.

What the missing layer needs to do

Whatever replaces the Figma comment for a built app has to do the things the canvas did well, in the new place:

What the canvas gave you	What a built-app loop needs
Anyone could comment, no install	Reviewers click a link or use a shared extension. Free, no dev toolchain
A comment pinned to a real element	Anchored by CSS selector + page URL, survives reloads and mobile
Builder saw frame, state, intent	Builder or agent sees selector, DOM snippet, screenshot, viewport, thread
Thread stayed on the thing	Thread stays on the pin, not scattered across Slack
Resolved when the change shipped	Resolved in a real commit + PR, re-checked on the deployed site

That last row is the one the canvas never quite did. "Was this actually fixed?" was always a follow-up conversation. On a live product you can close that loop automatically.

How Pincushion fills the gap

The review happens on the deployed product, and the people reviewing aren't opening an editor.

Reviewers install nothing real. An extension you share once, or a link. They click anything on the live site and type. Reviewers are free and unlimited.
The pin captures what a screenshot can't. Selector, DOM snippet, screenshot, viewport, and the full thread, bundled as an agent-ready work packet.
Your agent reads pins over MCP. One call in Cursor, Claude Code, Codex, or Windsurf pulls the whole context. It doesn't have to ask what was meant.
The loop closes. When the pin's resolved it carries the branch, commit, and PR. The deploy hook links the production URL, and the fix gets re-checked on the live site.

Same loop you had in Figma, point, discuss, fix, close, just on the thing that actually ships.

Figma isn't the villain here

This isn't an anti-Figma piece. For early exploration and handing design decisions to engineers, the canvas still earns its place. The point is narrower. The day your source of truth becomes the deployed app, the feedback loop has to move there too. Right now, for most teams skipping the canvas, it just falls into Slack and gets lost.

That's the layer we're trying to be. Not the canvas. The room where your team points at the live app and says "this is off," and the note turns into a fix.

Pincushion is free to start: pincushion.io

Collect client feedback on a website without endless revision rounds

MatttDamon — Wed, 24 Jun 2026 23:18:14 +0000

Most revision rounds don't spiral because the client is picky. They spiral because the feedback lost context on the way to you. Here's why that happens, what agencies try, and how to make each note clear enough to fix the first time.

Why a round actually spirals

A revision round is supposed to be one loop: client looks at the site, says what's off, you fix it, they look again. The trouble is that most of the feedback you get can't be acted on as-is.

"The hero feels cramped on mobile." Which phone. Which section. Cramped how. You're looking at the desktop build, they're looking at their phone, and neither of you is looking at the same thing. So you guess, you change something, you redeploy, you wait. They reply "no, the other one." That's a second round, and you still don't know what they meant.

Stack three or four of those and a one-day fix becomes a two-week thread. The client thinks you're slow. You think they're vague. Both of you are just paying for context that fell out of the message.

The fix isn't fewer revisions. It's making each note unambiguous the first time, so a round is one loop instead of three.

What a clear piece of feedback needs to carry

Every note that ends a round fast has the same things attached. Every note that drags one out is missing one of them:

The exact element. Not "the button near the top", the actual thing they clicked on.
The page and the screen size. A note about the live URL at 390px wide is a different note than the same words at desktop.
The thread in one place. So the back-and-forth stays on the spot being discussed, not forked across email, Slack, and a Friday call.
Enough for you to just do it. If you build with an AI agent, that means the note should be something the agent can pick up, not a paragraph you have to translate first.

None of that is exotic. It's just the stuff that email and screenshots quietly drop.

What agencies reach for, and where each falls short

1. Email and annotated screenshots

The honest default. Zero setup, every client already knows how. The cost is all in translation. Each screenshot is a small decode job (which page, which state, which element), the thread forks the moment two people reply, and nothing is anchored to the live page. Fine for a one-pager you touch once. A real drag once you're iterating.

2. A shared change list in Google Docs or a sheet

Better than scattered email, and clients can fill it in on their own time. But it's disconnected from the actual page. The client is describing in a sentence the thing they could just point at, and you're reading that sentence next to a screenshot trying to line them up. Organized, still ambiguous.

3. Proofing tools (Markup.io, Filestage, Ziflow)

These are genuinely good at what they're built for: structured proofing and sign-off on deliverables, with approval steps and version history. If your work is mostly static comps, PDFs, or marketing assets, they earn their place. The mismatch shows up on an interactive deployed app, where a comment on a flat capture can't follow a responsive layout or a changing state, and the output is a proof to approve, not work wired into your build.

4. Loom and screen recordings

Great for a client explaining a flow or a feeling that's hard to type. The catch is you can't act on a four-minute video. You watch it, you pause it, you transcribe it into a task list yourself. The context is rich and completely unstructured, which is the opposite of what shortens a round.

5. Feedback widgets (BugHerd, Marker.io, Userback)

Solid at turning a client note into a tracked ticket on a board, with the page and browser data attached. If your workflow ends at a clean ticket queue, they do that job well. The gap, if you build with a coding agent: the ticket is still written for a human to read and then re-enter as work.

6. Just get on a call

Fastest way to align in the moment, and sometimes the right move. The problem is the record. Verbal notes evaporate, you're scribbling while the client talks, and next week you're guessing what "make it pop" meant again. Good for the conversation, bad as the source of truth.

What changes when feedback lives on the live site

Put the feedback step on the deployed app instead of a screenshot, and the spiral mostly goes away. The client points at the real thing. The note carries where it was and what screen it was on. You stop guessing.

Why a round spirals	What removes that cause
"Which element did they mean?"	The note is anchored to a CSS selector and page URL, not pixels on a screenshot
"Was this desktop or mobile?"	Viewport is captured with the note, so the context is unambiguous
"Where's the rest of that thread?"	Discussion stays on the pin, not forked across email and chat
"The client won't install our tools"	Reviewers click a shared link and comment. Free, no account, nothing to set up
"I still have to translate it into work"	The note arrives as a work packet your coding agent reads directly
"Did we actually fix it?"	The pin closes against a specific commit and deploy, so the client sees what shipped

How Pincushion fits the agency loop

Pincushion is the feedback loop on the deployed app, built for people who ship with an AI coding agent. The part that matters for client work is that the reviewer does nothing technical and you get something you can act on.

The client installs nothing. You share a link or a browser extension once. They click any element on the live site and type what's off. Reviewers are free and unlimited, so adding the client (or three of them) costs nothing.
The pin carries the context a screenshot drops. CSS selector, DOM snippet, screenshot, viewport, page URL, and the full thread, captured the moment they drop the pin.
Your agent reads pins directly. One call to implement_approved_pins in Cursor, Claude Code, Codex, or Windsurf pulls the note plus its context. The agent has the element and the thread, so it isn't asking you what was meant.
The round closes itself. When the fix lands, the pin attaches the branch, commit, and PR, and the deploy hook links the production URL. The client sees "fixed and live" on the spot they pinned, instead of a "can you check this again?" email.

The client points at the live site. Your agent gets a work packet. The round is one loop, not a thread that won't die.

When this isn't the tool you need

If your client work is mostly static deliverables, brand decks, or PDFs going through formal sign-off, a proofing tool will serve you better than this. And if you only do the occasional one-page site and a couple of email screenshots get you there, that's a fine workflow.. don't add a tool you don't need.

The case for putting feedback on the live site is narrower than that. It's for when you're iterating on a deployed product, the client keeps reacting to the real thing, and the revision rounds are eating your margin. That's the spot where losing context on every note actually costs you.

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.

Figma comments don't work on your deployed app — here's what does

MatttDamon — Tue, 09 Jun 2026 20:40:34 +0000

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_pins in 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.

How I built an MCP server that turns visual feedback into code fixes

MatttDamon — Thu, 04 Jun 2026 05:56:38 +0000

Every web project has the same weird gap.

A stakeholder sees something on a page and knows exactly what feels wrong:

"This headline is too vague."
"Move this CTA closer to the pricing table."
"This form label reads like an internal field name."
"This is the wrong button."

But by the time that feedback reaches the developer, it has usually been turned into a screenshot, a Slack thread, a Loom, a Jira ticket, or a sentence like "can we tweak this?"

That handoff loses the most important part: the exact element on the exact page in the exact state where the feedback happened.

I built Pincushion to test a different shape:

A reviewer drops a visual pin on a live or staging page.
The pin captures implementation context: URL, selector, XPath, viewport, browser, screenshot, and the comment thread.
An AI coding agent reads that pin through MCP.
The agent implements the fix in the repo.
The commit and pin resolution close the loop.

The interesting part is not "visual feedback tool." Those already exist. The interesting part is treating a pin as an agent work packet.

Why screenshots are a bad substrate for agents

Screenshots are useful for humans. They are lossy for coding agents.

If I send an agent a screenshot and say "change this," the model has to infer:

Which route or page this is.
Which DOM element is being referenced.
Which source file owns that element.
Whether the issue is copy, layout, state, accessibility, or data.
What the stakeholder meant by the words around the screenshot.

Sometimes it gets there. Sometimes it works on the wrong component.

The fix was not to make the model better at reading screenshots. The fix was to stop using screenshots as the handoff format.

When a pin is dropped, Pincushion captures structured context:

{
  "pageUrl": "https://example.com/pricing",
  "selector": "main section.pricing button.primary",
  "xpath": "/html/body/main/section[3]/button",
  "viewport": { "width": 1440, "height": 900 },
  "browser": "Chrome",
  "thread": [
    {
      "author": "Sarah",
      "body": "This CTA should explain the trial. Try 'Start free project'."
    }
  ]
}

That is a much better input for an agent than a rectangle of pixels.

Why MCP was the right layer

The first version of this idea could have been a dashboard, webhook, or browser automation flow. I avoided that.

AI coding agents already have the tools that matter:

read files
edit files
run tests
inspect git state
make commits

The missing tool is not "drive a browser." The missing tool is "read the user's implementation intent."

MCP is a clean place to expose that intent. The Pincushion MCP server gives an agent tools like:

get_actionable_pins
implement_approved_pins
claim_pin
add_agent_reply
fix_and_resolve

The agent does not need to scrape a dashboard. It calls a tool, receives the work packet, and operates in the repo where it already has context.

The command I use most is effectively:

/implement

Behind that, the MCP server returns approved pins grouped by page, with selectors, thread context, and traceability data. The agent claims the pin, writes the change, and resolves it when the fix is done.

Design decision: thread context matters

At first I thought the pin body would be enough.

It was not.

The difference between:

Make this less vague.

and:

Make this less vague.

Sarah: The user already chose a plan by this point.
Josh: Good point. The CTA should confirm the next step, not resell the plan.

is huge.

Agents write better diffs when they have the "why," not just the "what." That is why implement_approved_pins returns the surrounding thread, not only the latest comment.

Design decision: fewer tools are better

Early MCP surfaces tend to expose every backend verb:

get annotations
list annotations
update annotation
approve annotation
claim annotation
resolve annotation
search annotations

That makes sense to a human API designer. It is not always best for an agent.

For implementation work, the agent usually needs a smaller set of intent-shaped tools:

"What should I work on?"
"Give me the implementation packet."
"Mark that I am working on this."
"Resolve it with a trace."

The more generic the tool surface, the more likely the agent is to choose the wrong tool or do extra work.

The lesson: design MCP tools around agent decisions, not database tables.

Design decision: no stakeholder diff approval

I originally had a preview/approval flow.

The idea was:

Agent proposes a diff.
Stakeholder approves the diff.
Agent lands the change.

It sounded responsible. It was wrong.

Most stakeholders do not read diffs. The preview step created a fake sense of safety and added another wait state.

The human reviewer who matters is the developer who merges the commit or PR. For Pincushion, the right loop is:

Stakeholder expresses intent visually.
Agent turns intent into a code change.
Developer reviews the code.
Pin resolution records what shipped.

No fake approval ceremony in the middle.

What I am testing now

Pincushion is soft launched. The Chrome extension is live, the MCP server is on npm, and I am looking for early testers.

The test I care about is not "does the landing page convert?"

The test is:

Can a developer install it without help?
Can a stakeholder drop a useful pin?
Can Cursor, Claude Code, Codex, VS Code Copilot, or Windsurf read the pin?
Can the agent implement a real change with less clarification than a screenshot or Slack thread?
Does the resolved pin give the team enough traceability?

If you build web apps with non-technical feedback loops and want to try it, the ask is simple: use it on one real page, drop 1-3 pins, and tell me where the loop breaks.

Link: https://pincushion.io

The broader bet

Most feedback tools are built around dashboards.

That made sense when humans were the only implementation path. But if the person doing the first pass is an AI coding agent, the dashboard should not be the center of gravity.

The center of gravity should be the IDE and the repo.

That is the bet behind Pincushion: visual feedback is not a ticket. It is an agent-ready work packet.