Prototype Review Checklist

Designer walks through each screen in the prototype side-by-side with the approved Figma file. Flag spacing drift, missing empty/loading/error states, and any component swapped for a one-off implementation instead of the design system primitive.

Test on at least Chrome desktop, Safari iOS, and Chrome Android. Common gotchas: 100vh on iOS Safari, sticky-header overlap with the keyboard, tap targets under 44px on mobile.

Run axe DevTools or Lighthouse accessibility audit. At minimum: keyboard-only navigation reaches every interactive element, focus rings visible, color contrast 4.5:1 for body text, form inputs have labels. Public-sector and EU customers will block GA without this.

Pull the Linear/Jira epic and tick each acceptance criterion against the running prototype. A criterion that's been silently descoped during the build is the most common reason a prototype review surprises the PM.

Empty list, single item, 10k items, network offline, 500 from upstream, expired auth token, duplicate submit. Prototypes routinely ship with the happy path polished and the error path showing a raw stack trace.

Run a k6 or Locust script against the staging endpoint with realistic payloads. Record p50, p95, p99 against the SLO target. If p95 is more than 2x the budget, treat it as a blocker — fixing perf after the architecture solidifies is much harder.

Only triggered when blocker-severity defects are present. Tech lead and PM agree on which blockers must be fixed before the next review and which can be deferred with a tracked ticket. Document the call in the review doc.

CODEOWNERS reviewer reads the PR end-to-end (not just diff hunks). Confirm linter and formatter pass, type checks are green, no TODO/FIXME without a ticket reference, no console.log or debug prints left in.

Semgrep or CodeQL for SAST; Snyk, Dependabot, or Renovate for SCA. Triage anything Critical or High before the review meeting; Medium can be deferred with a tracked ticket. Flag any GPL/AGPL dependency pulled in transitively.

Confirm unit test coverage on the new code is at or above the team threshold (commonly 70-80%). Look for flaky tests marked skip; flakes mask regressions. Verify CI runs the same matrix the prototype targets — Node version, Python version, browser set.

30-minute walkthrough of the data model, key abstractions, and any new infrastructure (queues, caches, jobs). Specifically probe: what breaks at 10x current load, what's hardest to change later, where are the implicit assumptions.

A new engineer should be able to clone, run locally, and hit a smoke-test endpoint within 30 minutes following the README alone. If the runbook covers a service that pages on-call, the on-call rotation needs to have read it.

Hit each external API (Stripe, Auth0, internal services) from the staging build and confirm payload shapes, error codes, and rate-limit handling match what the prototype assumes. Mocks drift from production; rediscovery at GA is expensive.

Run gitleaks or trufflehog against the branch. Confirm all credentials come from AWS Secrets Manager, Vault, or 1Password — never hardcoded, never in .env committed to git, never in CI logs.

BrowserStack or Playwright cross-browser run: latest Chrome, Firefox, Safari, Edge. Mobile: iOS Safari (current and current-1), Chrome Android. Note any degraded experience and decide whether to fix or document the limitation.

If the prototype touches PII, confirm encryption in transit (TLS 1.2+) and at rest (KMS), audit logging on read/write, and a deletion path for GDPR/CCPA right-to-delete requests. Loop in security if anything new is being collected.

Designer or PM facilitates; engineer observes silently. Give the user a task, not a tour. Record the session (with consent) so the team can rewatch the moments where the user got stuck. Five sessions surface roughly 80% of usability issues.

30-minute demo to PM, design lead, eng manager, and a customer-facing rep (CS or Sales). Capture every piece of feedback in writing during the call — memory loses 60% of it within a day.

PM and tech lead bucket items into Must-fix-before-build, Next-iteration, and Won't-do (with a one-line reason). Avoid the 'parking lot' anti-pattern where everything gets logged and nothing gets decided.

Only triggered when the outcome is Iterate and re-review. Book a follow-up review 1-2 weeks out and assign owners to each must-fix item before the calendar invite goes out.