In your stack
Pin client feedback to the component that renders it
Writhink gives your client one link to your deployed Next.js app. They click the element they want changed, and you get back the route, the element anchor, the viewport and a screenshot — enough to know which component file to open. Writhink is itself a Next.js App Router project, so this is the workflow we run on ourselves.
No credit card. Your client doesn’t need an account.
01
Review the build, not a picture of it
A Next.js app is not a static mockup. Data loads, a route transition swaps half the tree, a Server Component renders one thing and a client component takes over after hydration. Feedback taken on a Figma frame or a phone photo of a laptop screen misses all of that. Writhink puts the reviewer on the real deployed page and records where they clicked on that page.
You share one URL. The person opening it needs no account and no signup — the link token is the authorization. They type a display name and start pinning. That matters when the reviewer is a marketing lead who will look at the site twice and never open it again.
02
How a review runs
Nothing is installed on either side. The whole loop is a URL out and a prompt back.
- Step 1
Point a project at the URL
Production, a staging domain, or a preview URL. Writhink loads the page through its proxy so a comment can attach to a real DOM element instead of to coordinates on an image.
- Step 2
Send one link
No seats to buy, no invitation to accept, no app to download. Your client opens it in whatever browser they already have, on whatever device is nearest.
- Step 3
They pin what they mean
A click on the element, a sentence in the box, files attached if they have a reference. Replies are public, so the thread stays on the item instead of splitting across three email chains.
- Step 4
You read it with the page context attached
Route, element anchor, viewport size, device type, and a screenshot of the pinned spot as it looked when they left the comment.
- Step 5
Generate the prompt
Writhink rewrites the comments in plain language without inventing requests, merges duplicates, groups them by page and element, and produces one prompt to paste into Cursor, Claude Code, or whatever you code with.
03
What arrives with every pin
A sentence on its own is a guess. These fields are what turn it into a change you can actually make:
- The page URL, so you know the route — including the dynamic segment they were actually on, not the pattern.
- The element anchor, so the pin sticks to the node rather than to an x/y that drifts when the content above it changes.
- Viewport size and device type (desktop, tablet, mobile), which is usually the entire explanation for "it looks broken". Not the operating system, the browser or the handset model — Writhink does not record those.
- An automatic screenshot of the pinned area, captured at the moment the comment was left.
- Attachments — up to five files, 10 MB each — for the logo, the corrected copy, the competitor screenshot.
- A status: open, in progress, in review, resolved. Your client sees your public replies on the same item.
04
From a pin to a component
In a component world the useful question is not "where on the page" but "which component instance". Writhink does not read your source, so it cannot name the file for you. What it gives you is the pair that makes the file obvious: the route, and the element they clicked with its position in the rendered tree.
In practice you read the route, open the matching directory under app/, and the element anchor tells you whether they meant the shared header, one card inside a list, or the single instance in the sidebar. The screenshot settles it when the same component renders three times on the page. That is the whole trick: the client points at an instance, and you translate the instance into a component.
Because the reviewer is on the running app rather than on a pre-render, this works the same for anything that only exists after hydration — a dropdown they opened, a tab they switched to, a state your static HTML never contains.
05
Let your coding agent read the feedback directly
You probably already code with an agent. Writhink runs a remote MCP server at mcp.writhink.com, so the agent can pull the feedback itself instead of you pasting it over.
- Step 1
Connect once
In Claude Code: claude mcp add --transport http writhink https://mcp.writhink.com/mcp — Cursor and Claude Desktop connect to the same HTTP endpoint.
- Step 2
Authorize as yourself
OAuth 2.1 in the browser, once, and the agent acts as you — so there is no service key to land in a config file and get committed with the branch. What the grant actually covers is on /visual-feedback-for-ai-agents.
- Step 3
Work from the real items
Ask what is open on the preview and each item comes back with its route, the element the reviewer pinned and the screenshot — the same pair you would use to find the component yourself, handed to the agent instead. It can reply to the reviewer in their thread and push an item to in review once the branch redeploys.
- Step 4
Know the limit
The agent reads one active organization at a time, so switch first if you work across several, or it will look at the wrong set of projects and tell you everything is quiet. It also never reads your repository: your app/ tree stays on your machine, and the agent is the only thing holding both halves at once.
06
The two cases every Next.js project hits
A public production URL or a public preview deployment needs none of this: paste the URL, share the link, done. The general rule for choosing between a review link, the Chrome extension and the embeddable widget lives on /website-feedback-tool. These two cases are where a Next.js app actually spends its life, so they are worth spelling out.
| The situation | What to use | Why, and what it costs you |
|---|---|---|
| localhost:3000 during development | Chrome extension | The proxy fetches over the public internet and cannot reach your machine, so a review link has nothing to load. The extension annotates the dev server in the browser it is already running in. The consequence is who can review: only someone who can run the app. That makes localhost a fine surface for you and your own team, and the wrong one for a client — for them, push a preview. |
| A preview behind Deployment Protection, Basic auth, or your own login | Chrome extension, or open that one branch up for the length of the review | The proxy arrives as a stranger and meets the password screen, so a shared link shows the login instead of your build. Your browser is already through, which is why the extension works — but then every reviewer needs Chrome, the extension and their own access. Dropping protection on a single review branch is often the shorter path, if what is on it can be seen by anyone holding the URL. |
The extension is Chrome only. There is no Firefox, Safari, or Edge build, and that rules it out for a reviewer who will not switch browsers.
07
When the proxy is the wrong path even for a public page
A review link renders your page through Writhink's proxy, and most pages survive that without noticing. Some do not: a strict Content-Security-Policy, code that reads window.location.host and reroutes, a service worker that expects its own origin, a third-party embed that checks the referrer. The symptom is obvious — you open your own review link and the page is missing something it has in production.
The fix is not to loosen your headers for a review. Use the Chrome extension on the real page instead: same URL, no proxy in the path, comments in the same project. Check your own review link once before you send it to a client, and you will never find this out from them.
08
What this is not
There is no npm package, no plugin, and nothing to add to next.config.ts. Writhink does not build with your app, does not ship in your bundle, and does not touch your Core Web Vitals — the review happens on the page served through the proxy, or inside the extension. The only code you can optionally add is the embeddable widget script, and that is for collecting feedback continuously on a live site, not for running a review.
It is also the wrong tool for some jobs. Feedback from your own engineers, inline on the diff, is a pull request. Knowing what a thousand anonymous visitors did on the page is analytics or session replay, and Writhink does neither. Writhink is for the moment when one named person needs to tell you what to change about one specific page.
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
- Does it work with the App Router and Server Components?
- Yes. Writhink reviews the rendered page in the browser, so it does not care whether the HTML came from a Server Component, a client component, or a streamed Suspense boundary. What it records is the DOM element the reviewer clicked and the URL they were on when they clicked it.
- Can I review localhost?
- Not with a shared link. The proxy fetches the URL over the internet and cannot reach your machine. Use the Chrome extension for localhost:3000, or push a preview deployment and share a review link for that instead — which is the better move as soon as the reviewer is not you.
- Do dynamic routes come through correctly?
- Yes. The stored URL is the one the reviewer was actually on, so /blog/the-post-they-read is not flattened into /blog/[slug]. You see the specific instance they were looking at, which matters when only one of forty product pages has the broken image.
- Is there an npm package or a Next.js plugin?
- No. Nothing to install and no config to change. Reviews run through a shared link or the Chrome extension. The one optional piece of code is the embeddable widget script tag, which you would put in your layout only if you want feedback collected on a live site at any time.
- Can Cursor or Claude Code apply the feedback by itself?
- It can read it and act on the workflow around it. Connect the MCP server and the agent pulls the feedback with its page and element context, changes statuses, and posts replies to your client. Writing the code is still your agent doing what it already does; Writhink supplies the instructions and the context it needs.
- You say you use this on Writhink itself. On what?
- Writhink is a Next.js App Router project — the marketing pages, the dashboard and the review surface all live in it. We review changes to it with a Writhink link, which is why the element anchor and the screenshot exist in the shape they do.
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.