Running design crit when there's no canvas
Crit is a practice, not a Figma feature. It's the habit of putting real work in front of other people before it ships, and getting specific about what's off. Design engineers who build straight in code didn't opt out of that practice when they skipped the canvas. Most of them just don't have a room to do it in anymore.
What crit actually is
Strip away the tool and crit is three things. Real work, not a mockup of the work. Specific feedback tied to a specific element or state, not "this feels off" in the abstract. And a loop that closes, someone actually changes something because of what got said.
None of that requires a canvas. Design school crit happened on pinned-up prints. Figma just gave it a URL, a cursor, and a comment box. The tool was never the point, it was a convenient room.
Where the room used to be
If your team designed in Figma, crit had a home by default. Someone shared a file, people left comments on frames, you had a session where a handful of screens got picked apart before the engineer ever touched them. It worked because everyone could see the same thing at the same time and point at it.
Credit where it's due: Figma is still good at this for early exploration, for laying out three directions and picking one before any code exists. That part isn't broken. What's changing is how many teams get that far before code exists at all.
What changes when you design in code
A design engineer isn't waiting on a handoff. You open Cursor or Claude Code or v0, describe the screen, and something real exists in minutes. There's no frame. There's a running app, maybe on a preview URL, maybe on localhost, and it changes every time you prompt it again.
That's faster, genuinely. But it quietly removes the thing crit was leaning on: a stable, shareable artifact that isn't the production app itself. When the "design" and the "build" are the same object from minute one, you don't have a safe copy to gather around. You only have the real thing.
The canvas didn't create the need for crit. It just happened to be where crit lived. Take the canvas away and the need is still sitting there, unhoused.
The mistake teams make
Because the tool disappeared, a lot of teams quietly let the practice disappear with it. Nobody decided "we're skipping crit now." It just stopped happening, because there was no obvious place for a PM or a teammate to leave a note on a specific button on a page that's live, not a file.
So the feedback still happens, it just gets worse. A Slack message with a screenshot and a red circle. A comment in a standup that gets forgotten by Thursday. A client email describing "the thing near the top" that takes ten minutes to locate in the code. Crit didn't go away, it just lost its structure, and structure was most of the value.
What crit needs, regardless of where it happens
Whatever room you build for this, it has to do a handful of things or it's not really crit, it's just scattered opinions.
| What Figma crit gave you | What crit on a live app still needs |
|---|---|
| A comment attached to one frame, one element | A comment attached to one real element, by selector, not a vague description |
| Everyone looking at the same version | Everyone looking at the actual deployed state, not a stale screenshot |
| A thread that stayed on the thing being discussed | A thread that stays on the pin, not spread across Slack and standup |
| A session cadence, not a one-off note | Some recurring habit, even an informal one, not just ad hoc pings |
| Someone eventually resolved it in the file | Someone resolves it in a real commit, and it's checkable that they did |
Notice none of that row requires a canvas. It requires a shared surface, specificity, and a close-the-loop step. The canvas was one way to get all three. It's not the only way.
Doing crit against the live app
If you're a design engineer running crit without Figma, the practical version looks like this. Point at the actual running thing, whatever's deployed right now, not a description of it. Get people commenting directly on that, anchored to the real element so it survives the next deploy. Keep a cadence, even a loose one, a weekly look at what shipped this week is enough to start. And close the loop, when something gets fixed, it should be obvious that it happened and where.
That last part is the one people skip first, and it's the one that makes crit feel worth doing. If feedback disappears into a fix nobody can point to, people stop bothering to give it.
Where Pincushion fits
This is the whole reason Pincushion exists. Not to replace Figma, and not to be "Figma for the deployed app" either, that framing undersells what's actually different. It's a room for crit that happens to live on the running product instead of a file.
- Anyone can point at the live app and leave a note. No account required for reviewers, no separate design tool to learn.
- Each note is a real work packet. Selector, screenshot, DOM snippet, viewport, thread, not a vague Slack screenshot someone has to decode.
- Your agent reads it directly. Cursor, Claude Code, Codex, whatever you're building in, pulls the pin over MCP with the context already attached.
- The loop actually closes. The pin carries the branch, the commit, the PR, and gets re-checked against the deploy. "Fixed" is something you can point to, not something you're told.
That's crit, kept intact, just moved to where the work actually lives now.
The point, plainly
Skipping the canvas is a real tradeoff, and mostly a good one for a lot of teams right now. But it's a tradeoff about where design decisions get made, not about whether anyone needs to react to them before they ship. Those are two different questions, and it's easy to answer the second one by accident just because the first one changed.
Crit doesn't need a canvas. It needs somewhere to happen. If you build in code, that somewhere is the running app, and it deserves the same structure the canvas used to give it for free.