You have a staging URL, a launch date, and a list of stakeholders who all think the build is someone else's job to check. The goal of a pre-ship review is not to find every flaw in the universe. It is to produce a short, ordered list of issues that block launch, each one captured well enough that a developer or an AI agent can fix it without asking you a single follow-up question.
Here is a procedure that takes about 45 to 90 minutes for a typical marketing site or product surface, plus how to capture as you go.
Before you open the staging URL
Write down three things first. The browser and device you are testing on (for example, Chrome 131 on a 14-inch MacBook at 1512x982). The acceptance criteria the team agreed on, even if informal. The pages or flows that absolutely must work for launch to count as launch.
Then open a new review in another tab. You want capture ready before you start clicking, because the first time you find a bug you will not want to stop and set tools up. Cobalt Capture runs in the browser with no install and no signup, so the setup cost is opening a tab.
The order to walk the build
Do not start on the homepage and click around at random. Walk the build in roughly this order, because issues found earlier change what later issues mean:
- Critical paths first: signup, checkout, the primary form, the main conversion flow.
- Content pages that marketing or legal signed off on. Headlines, prices, dates, names.
- Navigation and footer, on every template at least once.
- Empty states, error states, and the 404 page. Type a fake URL. Submit the form with bad input.
- Responsive: shrink the browser to a phone width. Do not skip this even if a dedicated mobile pass is planned later.
- Performance smell test. Slow images, layout shift, fonts swapping in late.
This order surfaces blockers before cosmetic issues, which matters because your time will run out before your list does.
How to capture each issue so it gets fixed
For every problem worth logging, do the same four things in the same order.
Capture the screen. Click Capture screen, share the staging tab, and crop to the area that matters. Keep enough context that the receiver can identify the page. Do not crop down to a single button with no surroundings.
Drop a pin on the exact spot. If the issue is "this CTA wraps to two lines on tablet," the pin goes on the CTA, not vaguely near it. Numbered pins let you reference "item 3, pin 2" in conversation later.
Say what is wrong and what should happen. Dictate it if you are in Chrome or Edge; type it in Firefox. The pattern that works: observed behavior, expected behavior, where you saw it. "The pricing card shows $19 but the marketing brief says $24. URL: /pricing. Browser: Chrome 131, desktop." That is the whole comment. Two sentences and a URL beats a paragraph of context.
Mark severity in the comment itself. Prefix with "BLOCKER", "SHOULD-FIX", or "NICE-TO-HAVE". The receiver will sort by these, and so will you when you come back tomorrow.
For issues that are not visual (a missing redirect, a slow page load, a copy decision the team needs to make), use a free-floating comment with no screenshot. The format on the staging review page covers when each of these applies.
What "done" looks like for the review itself
You are done when the critical paths have been walked end to end, every blocker has a screenshot and a clear expected behavior, and your nice-to-haves are logged but visibly separated from the must-fix list. Publish the review. You get a public URL of the form /r/<slug> that anyone can read without signing up.
Send that link to two audiences with different framing. To the project manager or client, send the link itself; they can read items and post comments on individual ones, and you can mark each comment resolved as fixes land. To the developer, send the same review plus the markdown export at /r/<slug>/markdown. If your team works with an agent like Cursor or Claude Code, that markdown is what the agent reads. The markdown screenshots format explains why clean markdown works better than a video summary.
What to skip on a pre-ship pass
A staging review is not a full QA cycle and not a design critique. Resist three temptations. Do not rewrite copy unless it is wrong, not just suboptimal. Do not file accessibility issues found by gut feel; if accessibility matters for launch, run a separate accessibility review with the right tools. Do not log issues without a screenshot or a specific URL, because the developer will not know what you meant by Wednesday.
The other thing to skip: scheduling a meeting to walk through findings. If the review is captured well, the meeting adds nothing the link does not already carry. A team that runs staging reviews this way ends up with a record of what shipped and why, which is more useful three months later than any standup notes would be.
A checklist you can keep open in a tab
Open the staging URL. Open a new review. Walk critical paths, content pages, navigation, error states, mobile width, performance smell. Capture, pin, dictate, label severity. Publish. Send the review link to humans and the markdown URL to whoever (or whatever) is going to fix it. Mark comments resolved as the fixes come in.
If this is your first time running a pre-ship review with a written artifact instead of a call, the full walkthrough of a launch review shows the same flow with a real example.