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.

5 sections 23 steps Collects data
1

Design and User Experience

  1. 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.

  2. 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.

  3. 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.

  4. Capture UX issues in the review doc
    Collects paragraph
2

Functionality and Performance

  1. 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.

  2. 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.

  3. 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.

  4. Log defects in the issue tracker
    Collects list
  5. 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.

3

Technical Assessment

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

4

Integration and Compatibility

  1. 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.

  2. 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.

  3. 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.

  4. 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.

5

Feedback and Iteration

  1. 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.

  2. 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.

  3. 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.

  4. Record the go / no-go decision
    Collects list Collects paragraph Collects signature
  5. 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.


Sections 5
Steps 23
Category Software Development
Price Free to start
Need a different process

Browse hundreds of free templates across every team and industry.

Back to template library

Run Prototype Review Checklist with your team

Customize the steps, assign roles, set a schedule, and keep a complete record for every run.