A Launch Ready pre-launch QA walkthrough

1. Set up an isolated project

Start with a dedicated demo account and a website you own or are authorized to scan. Create a project for a fictional client, enter the synthetic staging URL, and mark its environment as staging. Keep account credentials, personal details, and customer information out of screenshots and recordings.

Plan entitlements determine which checks and workflow features are available. Verify the recording workspace's configured plan before demonstrating any plan-specific capability; code defaults are not proof of production settings.

2. Run a scan and read its coverage

Start a scan from the project and open its result when it completes. Review the readiness summary, category results, pages checked, and any unmeasured categories. The scan reports what it could reach and inspect; an unmeasured check is not a pass.

Coverage depends on the reachable pages, scan limits, captured markup, rendering, and enabled checks. A scan is a point-in-time review, not continuous monitoring or an automatic production-release gate.

3. Verify blocker evidence

Open a critical or high-priority finding and inspect its affected page, evidence, and suggested next step. Confirm it against the synthetic staging site before deciding what to fix. Scores and findings describe the scan result; they do not make a release decision for the team.

The public example report is a separate fictional fixture rendered with current report components. It is not a scan of the demo target and contains no customer report or share link.

4. Follow up manually

Use the finding as QA evidence, then make and review the code or content change in the website's normal workflow. Keep fix ownership, due dates, client approval, and accepted exceptions in the team's delivery record or issue tracker. Launch Ready reports findings; it does not implement fixes, export tickets, or approve a release.

Where the workspace plan supports finding-state or rule-tuning controls, document any exception and its reason rather than presenting it as a fix. Re-scan the synthetic staging site after the change and compare the new evidence and coverage.

5. Prepare a client handover

Review the report with the client, including remaining blockers, accepted exceptions, coverage, and checks that were not measured. In-app report sharing is available on every plan; branding and other capabilities vary by plan. Use the sharing controls in the product and keep client reports private from search.

An automated scan is one input to a launch review. Confirm important interactions and client-specific requirements manually, and keep the final release decision with the responsible team.

Plan requirements to verify

In-app report sharing is available on every plan. Free reports use Launch Ready branding, Pro reports can be neutral, and Agency reports can use agency branding. Full scan categories, rule tuning, and scheduled scans are included on Pro and Agency; API/MCP share creation and the deploy hook are Agency-only. These are code entitlements, not confirmation of the effective production configuration. Check the agency QA guide and current pricing before relying on a plan-specific feature.