Founder Operations Kit — Free Preview

1 Purpose

Code reviews are the single highest-leverage quality practice for an early-stage team. When your codebase is young and your team is small, every merged pull request shapes the architecture decisions you will live with for years. Reviews catch bugs before they reach users, but more importantly they distribute knowledge across the team, establish shared conventions, and create a written record of why decisions were made.

This SOP ensures every engineer — whether founder, first hire, or contractor — follows the same lightweight process so reviews stay fast, respectful, and effective.

2 Author Self-Checklist

Before requesting review, the author must confirm each item:

All tests pass locallyRun the full test suite; do not rely on CI alone.
No TODO or FIXME comments left behindResolve or convert to tracked issues before opening the PR.
Type checks and linting pass cleanlyZero warnings — not just zero errors.
PR description explains the “why”Include context, screenshots for UI changes, and migration notes if applicable.
Diff is scoped to a single concernSplit unrelated changes into separate PRs to keep reviews focused.
Sensitive data is excludedNo API keys, tokens, .env values, or PII in the diff.

3 Reviewer Checklist

Evaluate every PR against these four categories:

Correctness

Does the code do what the PR description claims?
Are edge cases and error states handled?
Do new tests cover the changed behavior?

Architecture

Does it follow existing patterns in the codebase?
Are responsibilities in the right layer or module?
Will this be easy to change six months from now?

Performance

Any unnecessary database queries or N+1 patterns?
Large payloads paginated or streamed?
Are expensive operations cached where appropriate?

Readability

Can a new teammate understand this without extra context?
Are names descriptive and consistent with conventions?
Is complex logic accompanied by brief comments?

4 Feedback Framework

Prefix every review comment with a tag so the author can prioritize quickly:

Tag	Description	Example
BLOCK	Must be resolved before merge — bug, security issue, or data loss risk.	“BLOCK: This SQL query is vulnerable to injection via the name parameter.”
SUGGEST	Recommended improvement; merge is fine either way, but this would be better.	“SUGGEST: Extract this into a helper — we use the same pattern in three other files.”
NIT	Minor style or naming preference. Never block a merge for a nit.	“NIT: We typically use camelCase for local variables in this repo.”
QUESTION	Genuine curiosity — helps the reviewer learn context or flags unclear intent.	“QUESTION: Is this timeout value from a benchmark, or should we make it configurable?”
PRAISE	Positive callout for clean code, clever solution, or good test coverage.	“PRAISE: Great job covering the null-input edge case here.”

5 SLA Timelines

Reviewers should complete their first pass within the following windows:

PR Size	Lines Changed	Review SLA
Small	< 100 lines	4 hours
Medium	100 – 400 lines	24 hours
Large	400+ lines	48 hours

If you cannot meet the SLA, post a comment acknowledging the review and give an ETA. PRs that exceed SLA without communication should be escalated to the team lead.

6 Hotfix Procedure

When production is broken, speed takes priority — but reviews still happen. Follow this abbreviated flow:

Open a PR with the prefix [HOTFIX] and tag the on-call reviewer.
One approval is sufficient — skip the normal two-reviewer requirement.
Merge and deploy immediately after a single approving review.
Backfill within 24 hours: add tests, update documentation, and conduct a brief post-mortem in your next standup.