You've clicked around your website and found things to fix. A typo on the pricing page. A menu that won't open on your phone. A photo that should be swapped. A button your customers say they can't find.
Finding them was the easy part. The hard part is sending them to your web developer in a way they can actually act on.
Why the usual ways go wrong
Most people send changes the way they'd send anything else, and each way loses something:
- A long email. Items get buried, replies split the thread, and "the button at the top" could mean any of five buttons.
- A document full of screenshots. Better, but the developer still has to guess which page each picture came from, and on which device.
- A phone call. Nothing is written down, so half of it is forgotten by the next day.
The result is the same every time: your developer comes back with questions for half the list, and the changes take twice as long.
What your developer needs for each change
For every item on the list, a developer needs to know:
- What's wrong, or what you want instead. "Change 'Contact us' to 'Book a call'" beats "fix the button".
- Which page. A link, not a description.
- Where on the page. Ideally a screenshot with the spot marked.
- Which device and browser. Many problems only happen on a phone, or only in one browser.
- How important it is. So they fix what matters first.
That's a lot to ask of you, your colleagues or your customers every time. For a closer look at what makes a report useful, see our guide to writing a bug report developers can use.
Step 1: Collect everything in one place
Instead of writing these details down, let a tool capture them. With pinreview, you add a small feedback widget to your site or use the browser extension. Then anyone reviewing the site clicks the thing they mean and types what they want changed.
Each comment automatically comes with a screenshot, the page link, the browser, the screen size, and the exact spot on the page. Your colleagues and customers can leave feedback too, for free and without creating an account.
Everything lands on one board, one card per change.
Step 2: Tidy the list
Before you send anything, spend ten minutes on the board:
- Merge duplicates. Three people will spot the same typo.
- Archive what you've decided against. Archived items are left out of the file you'll send.
- Mark what's important. Set a severity on each card, from low to critical, so your developer knows where to start.
- Add a note where it's unclear. A one-line comment saves a round of questions.
Step 3: Download everything as one file
Click Export at the top of the board. pinreview downloads a single ZIP file named after your project and today's date. Inside are two things:
- ISSUES.md — the full list. Every change with its page link, device, severity, your notes and the comment thread, grouped by the columns on your board.
- A screenshots folder — the picture for each change, numbered to match the list.
The .md ending means Markdown, which is plain text with light formatting. It opens in any text editor, and the tools developers use every day show it neatly formatted with the screenshots in place. You don't need to do anything special with it.
Step 4: Send it
Attach the ZIP to an email, or share it with a Google Drive or Dropbox link if it's too big to attach. Then add two sentences:
- What to work on. For example: "Please do everything in the To Do section. Ignore Done — that's already handled."
- When you need it. A date, not "soon".
Before you send it, remember the file includes the names and email addresses of the people who left feedback, plus any internal comments your team wrote. If that's a problem, delete those lines from ISSUES.md first. It's an ordinary text file, so you can edit it like any other.
Step 5: Check the work and close the loop
When your developer says a change is done, look at it on the site, on the same kind of device as in the screenshot. Then move the card to Done so whoever reported it can see it's handled.
When the next round of changes builds up, tidy the board and export again. Each export is a fresh list of where things stand.
Send a file, or invite your developer?
Both work. Pick based on how you work together:
- Send the export for a one-off job, a freelancer who isn't on your account, or a developer who prefers working from a file. It also works if your developer uses an AI coding assistant — here's how they can use it.
- Invite them to the project if they'll be working on the site regularly. They'll see new feedback the moment it arrives and can reply on each card. Team members count toward your plan's member limit; people leaving feedback don't.
Who can use it
Export is included on the Starter, Business and Agency plans. On the Free plan, the button shows a Paid badge. Only members of the project can export — people leaving feedback through a shared link can't download the list.
The bottom line
Your developer can only fix what they can find. Collect every change in one place with the screenshot and page attached, tidy the list, and send it as one file with a clear note about what to do first.
No more twenty-email threads. No more "which button did you mean?"