Get paid for the questions and custom requests you already get from followers.

Create your free Brillay link

Custom Work

Sell Code Reviews Online: Get Paid for the DM

A dev's guide to turning late-night code-review requests into a priced, packaged Brillay offer — sold from your bio, not a marketplace profile.

Updated September 2026

Get paid for this — with Brillay

Still reviewing PRs for free at midnight because someone asked nicely in your DMs? Publish a price, a line cap and a turnaround once — the next review request arrives paid upfront, with the branch link attached.

Brillay is a link in your bio where followers pay you directly for:

Custom WorkPaid QuestionsPersonalized VideosGoalsTips

Whoever watched your tutorial wants your eyes on their diff, not a Codementor booking or a Fiverr search. From your bio they pay once as a guest, and you review async inside the window you set — no call to schedule.

No monthly fee, you only pay a small platform fee when you get paid.

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 typeBest forWhat the follower submitsTypical creator response
Custom WorkPR, file, repository, bug, or MVP reviewRequest details, links, and optional file attachmentsWritten notes, a recorded walkthrough, or both
Paid QuestionsOne focused technical questionText and optional URLs; no follower-side file uploadA 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 modelRepresentative exampleCore transaction mechanicFit for a follower’s small code-review requestPrimary source
Mentor bookingCodementorThe buyer schedules access to a mentor, often as a live sessionBetter when the buyer wants booked time rather than an asynchronous deliverableCodementor
Freelance marketplaceUpworkA client posts or defines a job and evaluates contractor proposalsBetter for contractor hiring than paying a specific creator already followedUpwork
Gig marketplaceFiverrA buyer browses seller listings and selects a gigUseful for discovering a seller, but discovery is unnecessary when the buyer already knows the creatorFiverr Help Center
Corporate code-review servicePullRequest (now HackerOne Code)A company routes engineering work through a vetted-reviewer, managed review processBetter suited to engineering teams than an individual follower with one small requestHackerOne
Brillay Custom WorkA creator’s own Brillay pageThe follower buys a fixed offer directly and submits the requestDesigned for a priced, bounded deliverable sold from the creator’s bioHow 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.

BenchmarkPublished figurePrimary source
Lines of code per review sitting200–400 LOC; defect-finding ability drops beyond 400SmartBear / Cisco study
Defect discovery at that size70–90% of defects, over 60–90 minutesSmartBear
Inspection-rate ceilingDefect density drops above 500 LOC per hourSmartBear
Reasonable change size100 lines usually reasonable; 1,000 lines usually too largeGoogle Engineering Practices
In-team reviewer response normOne business day maximumGoogle Engineering Practices
Diff auto-loaded per file on GitHubFirst 400 lines and 20 KBGitHub Docs
Pull request diff ceiling on GitHub20,000 loadable lines, 1 MB raw diff, 300 filesGitHub Docs
Brillay Custom Work delivery time maximumUp to 5 daysHow 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.

OfferDeliverableAuthor’s illustrative pricedelivery time
PR WalkthroughRecorded video reviewing one pull request, line by line$30–7548–96h
Repo Health CheckWritten notes on structure, tests, README, and commit hygiene$25–5024–48h
Bug DiagnosisWritten review of a bug report and reproduction steps; diagnosis only, not a live fix$25–6024–72h
MVP Technical Gut-CheckWritten assessment of feasibility, stack fit, and rough cost$50–10072–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:

  1. Set up your Brillay page.
  2. Create a custom request offer with a specific name, such as “PR Walkthrough.”
  3. State exactly what code you will inspect.
  4. Choose written notes, a recording, or both as the deliverable.
  5. Set the price and delivery time window.
  6. 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.

Ready to get paid for the interactions you already get?

Create your free Brillay link