To sell code reviews online, package each review as a fixed-price Brillay Custom Work with a clear scope, delivery format, and turnaround window of up to 120 hours. Share the offer from your bio; a follower pays upfront and submits the code, so you can replace unpaid review DMs with bounded, paid work. Custom Work lets you offer clearly scoped commissions and services: you set the price, the scope and the delivery time, and followers submit a brief and pay before you start.
What can a follower submit for a code review?
A follower can submit a pull request link, a public repository URL, an attached code file, or a bug report with reproduction steps. Custom Work lets a follower explain what needs reviewing and attach up to five files; you set a delivery time of up to 5 days (how it works). The pull request, repository, or attached files define one deliverable for one follower: you review their code, rather than send every buyer the same file.
Common submissions include:
- A pull request or specific function
- A public GitHub repository
- An attached code file
- A bug report with reproduction steps
- An MVP architecture or stack decision
- A portfolio repository, README, or commit history
A follower might send a GitHub link and explain what is failing, or attach a file when the code is not in a public repository. GitHub's own documentation describes pull request reviews as the mechanism for commenting on changes, suggesting improvements, and approving or requesting changes before code merges (GitHub Docs) — the same review action a paid Brillay offer packages and prices.
GitHub caps a single pull request diff at 20,000 loadable lines or 1 MB of raw diff data and limits one diff to 300 files, with a maximum of 25 renderable files such as images or PDFs (GitHub Docs). GitHub also displays at most 250 commits in a pull request or compare view, which is a useful ceiling to name in a commit-history review offer. You can respond with written line-by-line notes, a recorded walkthrough, or both, depending on the scope you advertised.
For example, Priya might buy a review on Sunday night for a bootcamp project due Tuesday. Because your follower pays upfront and sends the code, you can review it Monday morning instead of sorting it out in late-night DMs. You can decline a request.
Should you use Custom Work or Paid Questions?
Choose Custom Work for any review that requires opening files, and Paid Questions for a single text answer. Custom Work accepts follower file attachments and creator-set delivery times of up to 5 days, while Paid Questions are one typed question and one written reply.
Use Custom Work when the request involves a defined deliverable, such as reviewing a pull request, inspecting a repository, diagnosing a bug, or recording a walkthrough — anything where you need to open the code rather than answer from memory.
Use Paid Questions for a narrower text-based question, such as “Remix or Next.js for this project?” or “Does this error indicate a state-management problem?”
| Offer type | Best for | What the follower submits | Typical creator response |
|---|---|---|---|
| Custom Work | PR, file, repository, bug, or MVP review | Request details, links, and optional file attachments | Written notes, a recorded walkthrough, or both |
| Paid Questions | One focused technical question | Text and optional URLs; no follower-side file upload | A text response |
The practical dividing line is the work involved. If you need to open files, inspect multiple parts of a repository, or produce a bounded deliverable, use Custom Work. If the follower needs a concise opinion that can be answered in text, use Paid Questions.
How does Brillay compare with developer marketplaces?
On Brillay, a follower buys one fixed-price deliverable from a creator’s own page; developer marketplaces use job posts, gig listings, or booked mentor sessions to match people who do not already know each other. That difference in default mechanic, not capability, is what decides which tool fits a follower's small request.
Codementor's marketplace centers on booking instant, scheduled, or long-term mentor sessions rather than asynchronous deliverables. Upwork's core flow has a client post a job and evaluate freelancer proposals before hiring. Fiverr has a buyer browse seller-created gig listings and select one. PullRequest, now HackerOne Code, routes reviews through a network of vetted senior-level reviewers for company engineering teams, not individual creator-follower orders. Your own commissions run on your own page at your own price, with the brief collected at checkout and the work paid for before you start.
| Platform model | Representative example | Core transaction mechanic | Fit for a follower’s small code-review request | Primary source |
|---|---|---|---|---|
| Mentor booking | Codementor | The buyer schedules access to a mentor, often as a live session | Better when the buyer wants booked time rather than an asynchronous deliverable | Codementor |
| Freelance marketplace | Upwork | A client posts or defines a job and evaluates contractor proposals | Better for contractor hiring than paying a specific creator already followed | Upwork |
| Gig marketplace | Fiverr | A buyer browses seller listings and selects a gig | Useful for discovering a seller, but discovery is unnecessary when the buyer already knows the creator | Fiverr Help Center |
| Corporate code-review service | PullRequest (now HackerOne Code) | A company routes engineering work through a vetted-reviewer, managed review process | Better suited to engineering teams than an individual follower with one small request | HackerOne |
| Brillay Custom Work | A creator’s own Brillay page | The follower buys a fixed offer directly and submits the request | Designed for a priced, bounded deliverable sold from the creator’s bio | How it works |
The distinction is not that other platforms cannot facilitate technical help. It is that their default mechanics solve different problems. A follower arriving from your tutorial usually wants your specific judgment without booking a call, posting a job, or comparing unrelated sellers.
How much code should one paid review cover?
Cap a single paid review at 200 to 400 lines of code. A SmartBear study of a Cisco Systems programming team found that developers should review no more than 200 to 400 lines of code at a time, because the ability to find defects diminishes beyond 400 LOC (SmartBear).
SmartBear reports that a review of 200–400 LOC spread over 60 to 90 minutes should yield 70–90% defect discovery, meaning a properly conducted review of code containing 10 defects would find between seven and nine of them. SmartBear research also records a significant drop in defect density at inspection rates faster than 500 lines of code per hour, and advises against reviewing for more than 60 minutes in one sitting.
Google's engineering practices documentation states that 100 lines is usually a reasonable size for a change list and 1,000 lines is usually too large (Google Engineering Practices). Google also sets one business day as the maximum time a reviewer should take to respond to a code review request (Google Engineering Practices) — an internal-team norm, which is exactly why a paid asynchronous offer has to publish its own window instead of leaving delivery time unstated.
| Benchmark | Published figure | Primary source |
|---|---|---|
| Lines of code per review sitting | 200–400 LOC; defect-finding ability drops beyond 400 | SmartBear / Cisco study |
| Defect discovery at that size | 70–90% of defects, over 60–90 minutes | SmartBear |
| Inspection-rate ceiling | Defect density drops above 500 LOC per hour | SmartBear |
| Reasonable change size | 100 lines usually reasonable; 1,000 lines usually too large | Google Engineering Practices |
| In-team reviewer response norm | One business day maximum | Google Engineering Practices |
| Diff auto-loaded per file on GitHub | First 400 lines and 20 KB | GitHub Docs |
| Pull request diff ceiling on GitHub | 20,000 loadable lines, 1 MB raw diff, 300 files | GitHub Docs |
| Brillay Custom Work delivery time maximum | Up to 5 days | How it works |
Those figures give you a defensible cap to publish in the offer itself. A stated ceiling of roughly 300 changed lines sits inside SmartBear's 200–400 LOC band, and a 48- to 72-hour window leaves room for the 60–90 minutes of concentrated review the same study associates with 70–90% defect discovery.
How should you price an online code review?
Price each named deliverable separately rather than charging one rate for every “code review.” A five-line function, a 300-line pull request, and an MVP architecture assessment are different workloads with different delivery times, so publish a separate fixed-price offer for each and cap the scope in the description before a follower buys.
The ranges below are author-created examples, not market benchmarks or earnings claims. They assume bounded submissions, asynchronous feedback, and no live debugging or implementation work. All of them clear Stripe's payment floor by a wide margin: Stripe requires a minimum charge of $0.50 USD or the equivalent in the charge currency (Stripe Docs), so pricing a review at $25 or more is a business choice, not a payment-processing constraint.
| Offer | Deliverable | Author’s illustrative price | delivery time |
|---|---|---|---|
| PR Walkthrough | Recorded video reviewing one pull request, line by line | $30–75 | 48–96h |
| Repo Health Check | Written notes on structure, tests, README, and commit hygiene | $25–50 | 24–48h |
| Bug Diagnosis | Written review of a bug report and reproduction steps; diagnosis only, not a live fix | $25–60 | 24–72h |
| MVP Technical Gut-Check | Written assessment of feasibility, stack fit, and rough cost | $50–100 | 72–120h |
Define the boundaries before the follower buys: what you will inspect, what you will deliver, and what is excluded. Delivery is one-time; additional work requires a new order. Useful limits include:
- One pull request or repository
- The languages or frameworks you will review
- A maximum scope defined by files, features, or review goals
- Written feedback, recorded feedback, or both
- Diagnosis versus implementation
- The delivery time window
- What happens if the submission is out of scope
A one-off Paid Questions offer should generally be positioned below a larger review because it involves a text response rather than opening files or producing a recording. If you are unsure whether followers will pay, start with one tightly scoped $25 review that names the code limit, deliverable, exclusions, and delivery time; the fixed offer lets buyers decide without starting another pricing conversation in your DMs.
What else can a developer sell through the same page?
The same Brillay page can carry Personalized Videos, Goals, Tips, and Brand Collaboration Inquiries alongside a code-review service, so one bio link handles the paid follower requests and brand inquiry forms a developer audience sends. Each paid offer is a one-time purchase, not a membership. Brillay supports creator payouts in 41 countries, with the fee breakdown on pricing.
Requests that commonly arrive through DMs can each become their own offer:
- Personalized Videos can celebrate a follower landing an engineering job or shipping a side project.
- Goals can fund a defined cost such as a laptop upgrade, open-source hosting, or a conference ticket.
- Tips let followers send a one-time thank-you, with nothing for you to deliver and no membership for them to join.
Developers can also package resume feedback, architecture opinions, and feasibility checks. The developers page organizes those offer types, while selling a resume review online covers another common job-search request. Browse the broader creator resources or review the available one-time paid request formats for additional options.
How do you publish your first code-review offer?
Create a Brillay page, add a specifically named Custom Work offer, state exactly which code you will inspect, set your price and delivery time, and put the link in your bio. Brillay is free to set up, with fees explained on pricing. You do not need to produce a review, file, course, or catalogue before the first order arrives; you only need to publish the service listing with its scope, price, and delivery time.
Payouts run through Stripe, and Stripe processing fees are deducted separately from creator earnings. The actual processing fee can vary by card and transaction, so treat 2.9% + $0.30 as an estimate rather than a guaranteed rate. Followers pay upfront and you deliver later, but no payment setup can guarantee against chargebacks, so keep your scope, exclusions, and delivery records clear.
To launch an offer:
- Set up your Brillay page.
- Create a custom request offer with a specific name, such as “PR Walkthrough.”
- State exactly what code you will inspect.
- Choose written notes, a recording, or both as the deliverable.
- Set the price and delivery time window.
- Add the page to your video descriptions, profile bio, or pinned comment.
Your offer should describe the outcome rather than simply say “I review code.” “Recorded feedback on one React pull request within 48–96 hours” gives the buyer a clearer expectation than an open-ended review promise.
A ready-to-copy example for a PR Walkthrough offer description:
Send me a link to one open pull request (up to ~300 changed lines) in a JavaScript or Python repo. I'll record a 10–15 minute screen-share walking through the diff line by line — what works, what I'd change, and any bugs I catch. Delivered within 72 hours. Diagnosis and suggestions only; I won't push code or fix the PR myself.
Swap the language, line-count cap, and delivery time to match your own stack and availability. The same structure — what to submit, what you'll deliver, what's out of scope, and the delivery time — works for a Repo Health Check or Bug Diagnosis offer too.
Frequently asked questions
How do I get paid to review code online?
Create a fixed-price Brillay Custom Work offer, define the code and feedback included, and share it through your bio. Followers can submit the request and pay upfront without creating an account. You can set a custom request delivery time of up to 5 days.
How much does Brillay charge?
Brillay's own platform fee is separate from card processing: No monthly fee, you only pay a small platform fee when you get paid. 8% platform fee when a follower pays for work, 5% platform fee on tips and goals. Card processing is separate. Payouts run through Stripe, and Stripe processing fees are deducted separately from creator earnings. The actual processing fee can vary by card and transaction, so treat 2.9% + $0.30 as an estimate rather than a guaranteed rate.
Do I need a certain follower count or verified credentials?
No follower minimum is required to start selling on Brillay. Setting up a page is self-serve: pick a username, turn on offers, and publish without an application, follower minimum, or credential-vetting gate. Describe your experience, scope, and capabilities accurately in each offer.
Can a follower send a whole repository or attach a file?
A Custom Work offer allows the follower to include request details, repository links, and file attachments.
Create your free Brillay page and publish your first code review offer.
Keep reading
New in the library
Ready to get paid for the interactions you already get?
Create your free Brillay link