BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This code review checklist template structures a team session where you agree on what 'good' looks like in a PR — correctness, security, performance, maintainability, and style — before the first reviewer opens the first pull request.
Use this when onboarding a new engineering team, when your review process is inconsistent (different reviewers flag different things), or after a production incident caused by something that should have been caught in review.
The whiteboard session takes 45–60 minutes. Run it with the full engineering team — every person who will both author and review code should be in the room. The checklist is the team's shared standard, not a manager's decree.
Write the questions reviewers should always ask about logic and behavior: Does the code do what the ticket says it should do? Does it handle all the edge cases named in the acceptance criteria? Are there untested code paths? Does it produce correct output for the test cases?
Write the security questions every reviewer should check: Are inputs validated and sanitized? Are there SQL injection, XSS, or other injection risks? Are secrets handled correctly (not in code, not in logs)? Are permissions and access controls correctly enforced? Is user data handled per policy?
Write the performance questions for your context: Are there N+1 queries? Are expensive operations cached where appropriate? Is the code efficient at the scale the product operates at? For mobile: are there main-thread operations that should be backgrounded?
Write the questions about long-term code quality: Is the code readable without excessive comments? Is complexity appropriate (not over-engineered, not under-structured)? Are abstractions at the right level? Would a new engineer understand this in six months?
Write the team's style expectations: Does the code follow the style guide? Are tests written for new behavior? Is the PR appropriately sized (not a 3000-line monster)? Is the commit message meaningful? Is the branch name following the convention?
Before writing the checklist, pick a recent incident, bug, or PR that could have been caught in review. Use it as the motivating example. The checklist is more convincing when the team sees a real case where it would have helped.
Write Correctness, Security, Performance, Maintainability, and Style on the board as column headers. Leave room under each for three to five specific questions. The structure is already defined — the team fills in the specifics.
For each category: ask 'What's the most common mistake we make or miss in this area?' Write the answers as review questions. The team's own pain points produce the most relevant checklist items.
For each checklist item: is this something reviewers should always check, or something they should check when it's relevant? 'Always' items go on the master checklist. 'Sometimes' items go on a reference list. The master checklist should be completable in five minutes — not exhaustive.
Write the two or three items that are absolute blockers — things that will prevent a PR from being approved regardless of other factors. Circle them in red. These are the things the team never ships past, no exceptions.
BoardSnap reads the five categories, their checklist items, and the non-negotiable blockers. The output is a structured code review checklist ready to put in the team's engineering handbook or PR template.
Code review checklists written by one senior engineer in a doc get ignored. Code review checklists written on a whiteboard by the whole team — where everyone debated which items belong and which don't — get used. Ownership produces adherence.
BoardSnap converts the team-owned checklist into a clean, shareable document. It goes into the PR template, the engineering onboarding guide, and the handbook — all derived from one whiteboard session.
Short enough to complete in five minutes for every PR. If the checklist has 30 items, reviewers will skim it or ignore it. Aim for 12–15 total items across five categories. Put the most critical items first in each category — if a reviewer only reads the first two items per category, they've covered the most important ground.
Both. Items that can be automated (linting, test coverage thresholds, secret scanning) should be automated — these are CI checks, not manual review items. The manual checklist should focus on things that require human judgment: correctness, logic, security decisions, and readability. Don't waste human review time on things a linter can catch.
Create a base checklist for all PRs and supplementary checklists for high-risk areas (payments, authentication, mobile performance). Keep the base checklist universal — five minutes for any PR. The supplementary checklists add five to ten minutes for high-risk changes.
The free tier gives you one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every board you snap.
No exporting, no transcription. Snap the board, get the action plan.