The problem only shows up halfway through a scroll. Will the screenshot catch it?

It captures what is on screen when the comment is created, so yes, provided they pin while it is happening. That is worth putting in the one sentence you send with the link. If the state is too brief even for that, a short screen recording attached to the comment is the reliable route.

Does Writhink know about my Framer breakpoints?

No. It records the viewport width in pixels plus a device class of desktop, tablet or mobile. That is more useful than a breakpoint name in any case, because clients browse at widths nobody designed for and the number tells you which of your layouts they were actually inside.

Will a scroll-heavy site load correctly through a review link?

Usually. Your real published page is served through a proxy so pins can attach to elements rather than to a flat image. If one particular effect breaks in that context, review those pages with the Chrome extension on the direct URL instead — same pins, same screenshots.

Can my client attach a video?

Up to five files per comment, 10 MB each. A trimmed screen recording fits comfortably. An unedited phone video of a monitor generally does not, and is worth less than the pin next to it anyway.

Does my client need a Framer account?

Neither a Framer one nor a Writhink one. Framer's own comments live in the editor, for people you invite into the project, which is a reasonable tool for you and a collaborator. The review link is a URL and a display name, which is what a client will actually use.

In your stack

Feedback on a moving target, pinned at the moment it looked wrong

Publish, copy the staging URL, send one Writhink link. Your client clicks the thing that is wrong while it is wrong, and the pin keeps the three facts you would otherwise have to guess at: which element, how wide their window was, and what the page looked like right then.

Start for free

No credit card. Your client doesn’t need an account.

The complaint you cannot reproduce

Framer sites move. The hero eases in on scroll, a section sticks and then releases, a card lifts under the pointer, one route transitions into the next. A large share of what your client sees is a state that lasts under a second.

Which produces the worst feedback in web work: "the headline jumps". You open the page, scroll at your own speed on your own monitor, and nothing jumps. So you scroll again, slower. Then you ask them to record their screen, and what arrives is a photograph of a laptop taken with a phone.

A pin fixes that — not by capturing the animation, which it does not do, but by capturing the conditions the animation ran under. Element, viewport width, device class, and a still of the page at the instant the comment was written.

Four things the pin keeps

Between them, these are usually enough to reproduce a transient bug on the first attempt instead of the fifth.

The element, not the region: the pin anchors to the thing they clicked, so “the headline” becomes a specific layer rather than the top third of a hero you have several variants of.
The exact viewport width, not a breakpoint name — the number their window was actually at. Framer's breakpoints are discrete and real windows are not, so a client sitting at 1180 is between two layouts you designed and neither one is being tested.
The device class: desktop, tablet or mobile travels with the comment. What Writhink does not record is the operating system, the browser or the model of the handset, so if a bug turns out to be specific to one phone you will still have to ask.
The screenshot, taken as they comment. This is the only record of a transient state. The scroll position moves on, the transition completes, the hover ends — the image does not. It is the reason a mid-animation complaint survives the trip to you at all.

The same bug, reported two ways

A message at nine in the evening

"The hero glitches when you scroll"
No width given, so you test at whatever your monitor is
The state being described is over before you look at it
Three messages that turn out to be one sticky section
You reply asking for a video and lose a day waiting

A pin left in the moment

The comment sits on the layer that glitched
The window width is recorded, along with desktop, tablet or mobile
A still of the page at the instant it looked wrong
Duplicates merged before the list ever reaches you
A short screen recording attached, when a still could not carry it

Running a review on an animated site

Step 1
Publish and take the staging URL
Framer's staging domain is public, which is all a review link needs. On a launched site, point the project at the real domain instead.
Step 2
Add the pages, then give one instruction
The instruction is: pin it while it looks wrong, not after you have scrolled past. Everything else about the pin happens by itself, and there is nothing for your client to install or sign up for.
Step 3
Ask for a clip when a still will not carry it
Some motion problems need motion. A comment takes up to five attachments of 10 MB each, which is a trimmed screen recording rather than a two-minute phone video, so tell them to keep it to the part that breaks.
Step 4
Sit in the review with them, if it is a big one
Turn live collaboration on for the project and you can see who is in the review, where their cursor is, and pins as they land. Ten quiet minutes beats a scheduled walkthrough call.
Step 5
Close the round and generate the list
Comments come back rewritten clearly, duplicates merged, grouped by page and element with priorities set. What the pass refuses to do is decide what "it feels janky" means — that line arrives marked unclear, with its screenshot, and the prompt asks for a reply you can send back.

What the pin does not know

It does not store the scroll offset as a field, and it cannot replay the animation. The evidence for a mid-transition state is the screenshot, which is precisely why the instruction to pin while it is wrong earns its place in the message you send.

It has no idea what your breakpoints are, which variant is active, or that a component even has a hover state. Writhink has no Framer plugin and never appears on your canvas; it works on the published page from the outside, seeing what a visitor sees and nothing more.

And it will not hand you a browser version or a phone model. Device class and viewport width are the pair it captures, which covers most responsive bugs and leaves the rare handset-specific one to a conversation.

When the proxy is the problem

A review link serves your published page through Writhink's proxy so that pins can attach to real elements. Heavy Framer sites usually come through intact. Occasionally an effect that leans on something the proxy sits in the middle of will misbehave, and the page reviews badly enough that your client is reporting the proxy rather than the site.

The fallback is the Chrome extension. It loads nothing of its own — you are on the direct URL in your own browser, pinning as you go, with the same screenshots and the same output at the end. The difference is that you are the one clicking, so it covers your QA pass rather than the client's round.

From the list to the build

For changes you make by hand in Framer, treat the output as a brief and work down it: page, element, width, screenshot, priority, one line each. Design clients write the vaguest feedback of any client group and no tool fixes that at the source, so the useful behaviour is refusing to invent meaning — rewrite what can be rewritten, merge what repeats, flag the rest.

For code components, or for the day the Framer design gets rebuilt in React, the same prompt pastes into Cursor, Claude Code or ChatGPT with the metadata intact. "This overlaps below 480" is a request an assistant can act on. "Make it nicer" is not, and it will arrive labelled as such rather than quietly turned into something specific nobody asked for.

Before you count on it

Writhink is in open beta: everything described here is available and free, no credit card. Paid plans are announced but not purchasable yet. The one limit that applies today is five AI prompt generations a month per organization.

FAQ

Questions people actually ask

The problem only shows up halfway through a scroll. Will the screenshot catch it?: It captures what is on screen when the comment is created, so yes, provided they pin while it is happening. That is worth putting in the one sentence you send with the link. If the state is too brief even for that, a short screen recording attached to the comment is the reliable route.
Does Writhink know about my Framer breakpoints?: No. It records the viewport width in pixels plus a device class of desktop, tablet or mobile. That is more useful than a breakpoint name in any case, because clients browse at widths nobody designed for and the number tells you which of your layouts they were actually inside.
Will a scroll-heavy site load correctly through a review link?: Usually. Your real published page is served through a proxy so pins can attach to elements rather than to a flat image. If one particular effect breaks in that context, review those pages with the Chrome extension on the direct URL instead — same pins, same screenshots.
Can my client attach a video?: Up to five files per comment, 10 MB each. A trimmed screen recording fits comfortably. An unedited phone video of a monitor generally does not, and is worth less than the pin next to it anyway.
Does my client need a Framer account?: Neither a Framer one nor a Writhink one. Framer's own comments live in the editor, for people you invite into the project, which is a reasonable tool for you and a collaborator. The review link is a URL and a display name, which is what a client will actually use.

Start

Send one link. Get feedback you can build from.

Your clients comment right on the page — no account, no screenshots, no voice notes. Writhink sorts the comments and writes the prompt for your AI.