Prototype Review Checklist
Steps a product engineering team runs to review a working prototype before promoting it to a funded build — covering design fidelity, functionality, technical health, integration, and stakeholder feedback.
Design and User Experience
-
Compare prototype against Figma mocks
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.
-
Run the core user flow on mobile and desktop
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.
-
Audit against WCAG 2.1 AA basics
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.
-
Capture UX issues in the review docCollects paragraph
Functionality and Performance
-
Walk the happy path against acceptance criteria
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.
-
Exercise edge cases and error states
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.
-
Capture p50 and p95 latency for the core flow
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.
-
Log defects in the issue trackerCollects list
-
Triage blockers with the tech lead
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.
Technical Assessment
-
Review the PR against the team style guide
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.
-
Run SAST and dependency scans
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.
-
Check test coverage and CI signal
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.
-
Walk the architecture with the staff engineer
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.
-
Confirm README and runbook are usable
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.
Integration and Compatibility
-
Verify upstream API contracts in staging
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.
-
Validate secrets are pulled from the vault
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.
-
Run the browser and OS compatibility matrix
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.
-
Confirm data handling matches the privacy policy
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.
Feedback and Iteration
-
Run a usability session with 3-5 target users
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.
-
Demo the prototype to stakeholders
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.
-
Prioritize feedback into the backlog
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.
-
Record the go / no-go decisionCollects list Collects paragraph Collects signature
-
Schedule the re-review session
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.
Use this template
Copy it to your account, customize the steps, and run it with your team in minutes.
Browse hundreds of free templates across every team and industry.
Back to template libraryRun Prototype Review Checklist with your team
Customize the steps, assign roles, set a schedule, and keep a complete record for every run.