You have a staging URL, a launch date that already feels close, and a list of people who all want to weigh in. The goal of the next hour is simple: walk the site, capture what is wrong or unclear, and hand the developer or agency something they can fix tonight. Here is the workflow that gets you there without installing anything.
Step 1: Open a review tab next to staging
In one browser tab, open the staging site. In a second tab, start a new review. Nothing to install, no signup screen blocking you. The review tab is where every screenshot and note will collect as you go. Keep both tabs visible if you have the screen space; otherwise alt-tab between them.
Outcome: a blank review is ready to receive items, and staging is loaded in the next tab.
Step 2: Write your checklist as floating comments first
Before you start capturing screens, add a handful of free-floating comments to the review with no screenshot attached. These are your checklist headings: Homepage, Pricing, Checkout, Mobile nav, Forms, 404 page, Analytics and tracking, and whatever else applies. You will slot screenshots underneath each as you find issues.
Outcome: the review now has a skeleton that mirrors the launch checklist, so nothing important gets skipped.
Step 3: Capture the first issue and pin the exact spot
Switch to staging. When you spot something wrong, switch to the review tab, click Capture screen, and pick the staging window. The current frame is drawn to a canvas. Drag a rectangle around the relevant region so the screenshot is tight, not a 4K wall of pixels. Drop a numbered pin on the exact element you are talking about: the cut-off heading, the wrong price, the broken form field.
Outcome: one captured item, cropped to the relevant area, with a pin marking the spot a developer needs to look at.
Step 4: Dictate the comment instead of typing it
Add the comment by dictating. In Chrome or Edge, the dictation button uses the browser's built-in speech recognition, so you can talk through what is wrong while you are still looking at it. Firefox users will need to type. Say what you expected, what you saw, and any context the developer needs ("this is the staging build from this morning, logged out, on desktop Chrome"). Speaking is faster than typing and tends to produce more useful context because you describe rather than summarise.
Outcome: the screenshot has a comment that reads like a real bug report, not a one-word note.
Step 5: Walk the rest of the checklist
Repeat capture, crop, pin, and comment for every issue. A practical order that catches the most before launch:
- Top of the homepage at desktop width, then resize the window narrow and capture mobile layout problems.
- Every primary navigation link, confirming it lands on the right page with the right title.
- Forms: submit one with valid data, then one with invalid data, capturing the error states.
- Any flow involving payment or signup, even if you stop short of the final submit.
- The 404 page (type a nonsense URL).
- View source or DevTools for missing meta tags, then capture those too.
If you also want to file accessibility blockers, the same capture flow works for an accessibility review pass using your contrast checker or screen reader output as the source.
Outcome: a review with twenty to fifty items covering the surface area that matters at launch.
Step 6: Publish and grab the public link
Hit Publish. The review gets a short URL of the form /r/<slug>. Anyone with that link can read it, no login required. If you started without an account, the review is kept for 30 days; sign in with Google or a magic link to claim it permanently. This is the link you paste into Slack, email, or your pre-launch staging review ticket.
Outcome: one URL that contains the entire pre-launch punch list.
Step 7: Send the right format to each receiver
Different people need different formats from the same review:
- The project manager and the client get the public link and a PDF export for the meeting.
- The developer gets the link plus the markdown version at
/r/<slug>/markdown. If they work with an AI coding agent like Cursor or Claude Code, they can paste that markdown straight in. See how markdown screenshots travel for what that handoff looks like. - Legal or compliance reviewers tend to want the Word document export so they can redline it.
Outcome: every stakeholder has the version of the review that fits their tool, all generated from the same source.
Step 8: Triage replies and mark items resolved
People with the link can comment on individual items, so the developer might reply "fixed in commit abc123, please recheck" on item 14. Click the item, re-test on staging, and mark it resolved. The owner-facing analytics page shows visit counts and rough geography, which is a quick way to tell whether the agency in another timezone has actually opened the review yet.
Outcome: a single source of truth for what is fixed, what is not, and what blocks launch.
Step 9: Do one final pass the morning of launch
Open the review and walk the unresolved items one more time on staging. Anything still broken becomes a go or no-go conversation, not a surprise at 4pm. If the team uses similar review cycles for ongoing work, the same flow doubles as QA bug reporting and client feedback rounds after launch.
If you want to see how Cobalt Capture fits the rest of your stack before you start, the pricing page spells out what is free and what an account adds.