Price a code review by lines of code and realistic review speed, not by feature count: the SmartBear/Cisco peer code review research puts effective inspection speed at 300 to 500 lines of code per hour, so a 200-line script fits one flat-priced deliverable while a 5,000-line codebase needs several priced hours or a multi-part scoped engagement.
Developers who review code for other people — mentors, freelance reviewers, tech-Twitter regulars fielding "can you look at my PR?" DMs — tend to price by gut feeling: a flat "$50 for a look" regardless of whether the repo is 80 lines or 8,000. That undercharges large codebases and overcharges small ones. A lines-of-code method fixes both.
How many lines of code can you actually review in an hour?
Effective reviewers inspect no more than 300 to 500 lines of code per hour, and no more than 200 to 400 lines in a single sitting, according to SmartBear's peer code review research. Use 400 lines per hour as a planning midpoint: a 2,000-line pull request is roughly a five-hour review, not a quick look.
Those numbers come from a joint SmartBear and Cisco Systems study that SmartBear's own case-study page calls "the world's largest published case study of peer code review," spanning 2,500 reviews of 3.2 million lines of code written by 50 developers over a 10-month period (SmartBear, Cisco Systems case study). The superlative is SmartBear's own characterization of its data set, not an independent ranking of code review studies. SmartBear reports a significant drop in defect density at review rates faster than 500 lines of code per hour (SmartBear, "Best Practices for Peer Code Review"), which is why reading faster than 500 lines per hour should not be treated as a discount a reviewer can pass to a buyer.
SmartBear also caps how long one review sitting should run. Its guide to the code review process states:
After roughly 60 minutes, reviewers simply wear out and stop finding additional defects.
That sentence is quoted verbatim from SmartBear's guide to the code review process, which recommends a maximum of 60 to 90 minutes per review session. Translate the research into pricing this way: estimate hours from line count divided by review speed, then price the hours — not the file count or the number of functions touched.
How should you price a review of a small script or single file?
Price a single file under roughly 300 lines as a flat, low-priced deliverable rather than an hourly quote, because 300 lines takes about 36 to 60 minutes at the 300-to-500-lines-per-hour rate SmartBear publishes. On FanBell that means either a Paid Private Question or a small Creator Service.
If the request is truly text-only — "does this regex have a bug?" pasted inline — a Paid Private Question works: the fan sends text, the creator replies by text or voice, and price plus reply time are the only two settings the creator configures. The moment a fan needs to attach an actual file, the request belongs in a Creator Service instead, because Paid Private Questions carry no file or video attachments in either direction, while a Creator Service lets the fan attach files when they order.
The illustrative anchor for a single-file, sub-300-line review is $25–$45 for same-day or next-day turnaround, and the full arithmetic is this: 300 lines ÷ 400 lines per hour (the midpoint of SmartBear's published 300-to-500-lines-per-hour rate) = 0.75 review hours, multiplied by the $30–$60 effective hourly figure this guide assumes, rounded to the nearest $5. That band is derived arithmetic, not survey data — FanBell has run no code-review pricing survey, and the assumed hourly figure is explained under "What do the price anchors in this guide assume?" below.
How should you price a mid-size feature or pull request review?
A 300-to-3,000-line pull request needs roughly one to ten hours of review time at the 300-to-500-lines-per-hour rate SmartBear publishes, which puts it in scoped-deliverable territory rather than a single quick reply. Scope it as one deliverable with a fixed turnaround, never as an open-ended retainer.
Structure the listing around what gets returned: inline comments, a written summary of risks, a short must-fix versus nice-to-have list, and optionally a voice walkthrough of the trickiest part. Creator Service turnaround is set by the creator and capped at 5 days — 120 hours — in the product, so a 2,000-line pull request review might carry a 48-to-72-hour turnaround rather than same-day.
The illustrative anchor for this tier is $75–$450, and the arithmetic runs the same way: a 1,000-line pull request is 2.5 review hours (1,000 ÷ 400 lines per hour, SmartBear's published midpoint) and a 3,000-line pull request is 7.5 hours, which is $75 at the assumed $30 per hour and $450 at the assumed $60 per hour. A 400-line pull request sits near the bottom of that band, not the middle.
How should you price a review of a large app or repository?
A repository above roughly 3,000 lines rarely fits a single flat price, because 3,000 to 15,000 lines is six to fifty hours of review time at the 300-to-500-lines-per-hour rate SmartBear publishes. Scope the review to a defined slice of the codebase instead of accepting "review my whole app," then price that slice.
Google's engineering-practices documentation makes a related point about reviewable chunk size, though it is written for authors submitting changes rather than for external reviewers:
100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large, but it's up to the judgment of your reviewer.
That guidance is quoted from Google's eng-practices guide to small CLs. The same logic runs in reverse for pricing: quote per module ("I'll review your auth and payments code first") or per fixed time block ("a 6-hour pass covering whatever you flag as highest-risk"), and state plainly that a full-repository audit is a larger, separately scoped engagement. The illustrative anchor for this tier is $225–$2,250 — 3,000 lines is 7.5 review hours and 15,000 lines is 37.5 hours at SmartBear's 400-lines-per-hour midpoint, priced at the assumed $30–$60 per hour — and it is normally quoted per module rather than as one number.
Should you charge a flat fee or an hourly rate for a code review?
Charge a flat fee when the scope is bounded and predictable — a single file, a specific pull request, a named module — and charge hourly-equivalent blocks when the codebase is large or the scope is open-ended. Flat pricing is easier for a buyer to accept; hourly-equivalent pricing protects the reviewer when line count is unknown up front.
One anchor for what a developer's time is worth: the median annual wage for software developers was $135,980 in May 2025, according to the U.S. Bureau of Labor Statistics Occupational Outlook Handbook (BLS). That BLS figure is a full-time employment benchmark for US workers, not a suggested freelance rate and not a non-US figure — a scoped side review typically prices below a full consulting engagement, and the right number depends on experience, niche, and demand.
Reviewer effort is also not linear with formality. SmartBear reports that lightweight code review takes less than 20% of the time of formal inspection while finding a comparable number of bugs, so a heavyweight, checklist-driven audit is a legitimately more expensive product than a fast annotated pass.
What do the price anchors in this guide assume?
Every price band in this guide is derived arithmetic, not observed market data: FanBell has run no code-review pricing survey. Each anchor is the estimated review hours at SmartBear's 400-lines-per-hour midpoint, multiplied by an assumed effective hourly figure of $30–$60, rounded to the nearest $5.
That $30–$60 assumption sits below the roughly $65 per hour implied by the BLS median wage of $135,980 for software developers in May 2025 spread across 2,080 working hours.
| Codebase size (lines of code) | Review time at 300–500 LOC/hr | Best-fit FanBell format | Illustrative price anchor |
|---|---|---|---|
| Under ~300 LOC (single file/script) | ~36–60 minutes | Paid Private Question or small Creator Service | $25–$45 (at 300 LOC) |
| ~300–3,000 LOC (feature/PR) | ~1–10 hours | Creator Service | $75–$450 (at 1,000–3,000 LOC) |
| ~3,000–15,000 LOC (small app/repo) | ~6–50 hours | Multi-day Creator Service, scoped to specific modules | $225–$2,250 (at 3,000–15,000 LOC) |
| 15,000+ LOC (large repo) | 50+ hours | Creator Service scoped to a defined slice, quoted per module | Custom, priced per module |
Table footnotes. Review-time column: line count divided by the 300-to-500-lines-per-hour effective inspection rate published by SmartBear (Best Practices for Peer Code Review); for example, 3,000 lines ÷ 500 LOC per hour = 6 hours at the fast end, and 3,000 ÷ 300 = 10 hours at the slow end. Price column: the stated line count divided by SmartBear's 400-LOC-per-hour midpoint, multiplied by the assumed $30–$60 effective hourly figure, rounded to the nearest $5 — for example, 3,000 ÷ 400 = 7.5 hours, and 7.5 × $30 = $225. These are illustrative starting anchors to adjust, not a rate card, a survey result, or an earnings promise. Format column: FanBell's own product documentation for Paid Private Questions and Creator Services.
What besides line count should change your price?
Line count sets the baseline, but language familiarity, test coverage, and the stakes of the code move a quote up or down from it. At SmartBear's published 300-to-500-lines-per-hour band, the same 500 lines is a one-hour review at the fast end and about 100 minutes at the slow end.
Denser code lands slower still, so adjust the quote before accepting the request, never after reading starts. Five factors move a code review quote away from the raw line-count baseline:
- Language. A language reviewed daily goes faster than one rarely touched.
- Test coverage. Untested code takes longer to reason about safely than code with a solid test suite.
- Stakes. Payment, auth, and data-deletion code deserve more scrutiny — and a higher price — than a marketing page component.
- Deliverable depth. Inline comments only is faster than comments plus a written risk summary plus a recorded walkthrough.
- Legacy vs. fresh code. An undocumented legacy file is slower to review than code the author can walk through first.
SmartBear's peer code review white paper reports that the defect density reviewers find drops sharply once an inspection runs past 200 lines and is almost zero above 400 lines (SmartBear, "11 Best Practices for Peer Code Review"). Price a deep review of a 1,000-line file as several sittings rather than one, and state these adjustments in the listing so a fan understands why a security-sensitive file costs more than a UI tweak of the same line count.
Should a code review be a Paid Private Question or a Creator Service?
Use a Paid Private Question for a text-only question a fan pastes inline, and a Creator Service the moment the fan needs to send a file. The difference is media, not size: Paid Private Questions carry no attachments in either direction, while Creator Services accept a fan's file at order time.
| Decision factor | Paid Private Question | Creator Service |
|---|---|---|
| Fan can attach a file | No — text-only from the fan | Yes — files and images |
| Creator delivery formats | Text or voice reply | Text plus files, links, audio, video |
| Settings the creator configures | Price and reply time | Price and turnaround (capped at 120 hours) |
| Best fit by codebase size | Pasted snippet under ~300 LOC | Any review needing a repo, branch, or .zip |
Every row above reflects FanBell's own product documentation for Paid Private Questions and Creator Services. Put concretely: a pasted stack trace is a question, and a .zip of the repository is a service.
How do you scope a code review so it doesn't turn into unpaid work?
Scope a code review by naming exactly what is in and out before the fan pays: a line-count ceiling, which files are covered, the feedback format, and how many follow-up rounds are included. Without that boundary, "review my code" quietly expands into unpaid debugging or a second pass across unrelated files nobody agreed to.
Put the boundary in the listing itself: "Up to 500 lines across a maximum of 5 files; written comments plus a 3-bullet risk summary; one round of clarifying replies included." A 500-line ceiling also matches SmartBear's finding that reviewers should inspect no more than 200 to 400 lines in one sitting, so the listing promises at most two sittings of work. If a fan submits something well outside that ceiling — a 10,000-line monorepo against a 500-line listing — the creator can decline and refund the request rather than absorb the extra scope; FanBell's pricing page states that refunds are supported and may reverse the payment, transfer, and platform fee depending on the transaction status (FanBell pricing). For scoping any custom request before acceptance, see how to scope a custom creator request; for the pricing side, see how to price services without undervaluing your time.
A related, broader offer is a full MVP scope review, which evaluates whether a product plan is buildable rather than reviewing existing code — worth listing if founders ask for input before any code exists. Developers building an offer page from scratch can also see what a FanBell page for developers typically includes.
What does it cost to sell a code review on FanBell?
FanBell is free to start with no monthly fee and applies a 12% platform fee only when a fan pays. Card processing is separate: Stripe lists 2.9% + 30¢ per successful charge as its typical US online-card rate (Stripe pricing). A $200 review therefore nets roughly $170 after both.
FanBell's own FAQ states that there is no follower minimum and nothing to apply for, so a developer with a small but relevant audience can list a code review the same way a larger account can.
Frequently asked questions
How long should a code review actually take?
SmartBear recommends capping any single review session at 60 to 90 minutes and inspecting no more than 300 to 500 lines of code per hour, because detection quality drops once a reviewer works past about an hour. Split a large codebase into multiple sessions rather than one long sitting.
What's a fair price for reviewing a small script?
No single fair price exists, because the number depends on experience, language, and demand. A sub-300-line script reviews in about 36 to 60 minutes at SmartBear's published 300-to-500-lines-per-hour rate, which fits a flat, low-priced Paid Private Question or small Creator Service rather than an hourly quote.
Should I quote a full repository review as one flat price?
Usually not. A 15,000-line repository is 30 to 50 hours of review time at SmartBear's published 300-to-500-lines-per-hour rate, so it is better scoped as a per-module or per-time-block Creator Service ("I'll review your auth and payments code first") than as one flat number for "the whole thing."
Does FanBell take a cut of what I charge for a code review?
FanBell is free to start with no monthly fee and takes a 12% platform fee only when a fan pays. Stripe's typical US online-card processing of 2.9% + 30¢ per successful charge applies separately, on top of the platform fee.
Do I need a certain number of followers to sell code reviews?
No. FanBell's FAQ states that there is no follower minimum and nothing to apply for, so a developer with a small but relevant audience can sell a code review the same way a larger account can.
Keep reading
Ready to get paid for the interactions you already get?
Create your free FanBell link