PullRequest

Name: PullRequest
Brand: PullRequest

PullRequest (HackerOne Code) is a code-review-as-a-service platform that connects to source control systems, combines AI-assisted risk prioritization with a network of vetted human reviewers, and delivers inline feedback on bugs, maintainability, and security within developer workflows.

Est 2017|Valuation $36M|Raised $10.5M

LinkedIn 1K|Web traffic 7K|FTEs 21|HQ Austin, Texas, United States

MarketsApplication Security Testing (AST)

Published Oct 2, 2026

01Common complaints

- You need low-cost, always-on scanning across every repo/PR: automated tools like GitHub Code Security, Semgrep, or Codacy are typically more cost-effective and consistent at scale. - You cannot grant third-party reviewers access to proprietary source code: even with NDAs and on-prem options, some organizations will not pass vendor risk review. - Your bottleneck is not code review capacity: if merges are blocked by product decisions, unclear requirements, flaky CI, or large PR sizes, adding external reviewers may not materially improve throughput. - You require publicly documented compliance certifications (e.g., SOC 2 Type II) before procurement: lack of publicly available certification evidence may delay procurement until documentation is provided under NDA.

Deal disqualifiers (poor fit)

Organizations that cannot allow third-party access to source code for policy or compliance reasons
Organizations that require 100% PR coverage but cannot contract for it
Teams primarily needing automated SAST/SCA rather than human guidance

Product limitations explicitly indicated or implied

Partial PR coverage under Smart Review Selection (30–40% typical as stated by the vendor) may not match buyer expectations for full coverage.
Review turnaround is typically bounded by vendor business hours (the vendor notes reviews are typically completed during US business hours; turnaround varies by review size and complexity).

Vendor-acknowledged security/operational constraints

Vendor documentation indicates backups do not regularly include repository data and that code can be deleted from their systems subject to backup retention caveats.
External reviewers access the code being reviewed; the vendor provides file anonymization/exclusion options via pullrequest.yaml (vendor statement).

Roadmap

No concrete public roadmap dates were captured in the provided sources.

02Why they buy

Differentiators supported by available evidence

Human review as a core differentiator versus purely automated tools (vendor positioning and post-acquisition materials).
Integrations with common SCMs (GitHub/GitLab/Bitbucket/Azure DevOps) to surface reviewer feedback in existing workflows (vendor statements).
On-premise options for certain Enterprise customers and SCMs (vendor statements).

Where competitors may be stronger

Automated tools typically provide broader continuous coverage, standardized policies, and ecosystem integrations for CI/CD and compliance reporting.
GitHub-native solutions reduce vendor sprawl if an organization is already standardized on GitHub.

03Field reports

What’s available (limitations)

Third-party review coverage for PullRequest itself appears limited in major review platforms in the captured sources. One listing found appears to be for a different product and should not be treated as evidence about the PullRequest code review service.

The vendor site includes curated on-site testimonials from executive users; these are marketing references and are not independently verified in the captured sources.

Vendor-published testimonials (not independently verified)

Examples from the vendor homepage include:

Engineering leadership at a major automotive company describes the service as providing feedback they consider high quality and actionable.
A customer testimonial states the service caught issues before release.

These statements are vendor-published and do not include methodology or audit details.

Community mentions (limited specificity)

A community comment reported a positive anecdote about an external reviewer providing a good code review. This is an isolated comment without broader context (team size, plan tier, or timeframe).

Negative/critical feedback signals found

A buyer-guide page noted that the code review tool can be troublesome in how it displays diffs between source and changed code. The context suggests it may reflect an integrated experience; it is not a large sample of independent reviews but is a negative signal found in the captured sources.

Why customers choose it (inferred from positioning and available evidence)

Based on product messaging and press coverage, reasons include:

External reviewer capacity to reduce internal review bottlenecks
Security vulnerabilities identified earlier in development
Integrations that surface feedback within SCM workflows

Why some customers might leave (inference; limited direct evidence)

Inferred churn reasons include:

Cost at scale (seat-based, annual billing)
Preference for automated SAST/SCA tools that scan continuously on every PR
Security or compliance constraints around granting external access to proprietary source code

Available case study-like evidence

The vendor publishes customer metrics claiming substantially more internal review comments and materially less time spent reviewing code in marketing case studies. These are vendor-reported metrics without disclosed methodology in the captured excerpts (no baseline definition, measurement window, or sample size).

Practical buyer takeaway

Treat vendor-published metrics as hypotheses to validate via:

A pilot with pre/post metrics (PR cycle time, defect escape rate, security issues found in CI/CD vs post-release)
Measuring reviewer acceptance rates and developer satisfaction through surveys

04Best fit

Company size

Likely best fit:

20–500 engineers where internal reviewer bandwidth is constrained and the codebase complexity may justify a higher-cost service.
Smaller startups can benefit, but the seat price may be a larger portion of budget.

Industries

Potential fits:

SaaS, fintech, healthtech, and other environments where security and fast iteration are important.
Regulated industries if on-premise or SSO options meet vendor risk requirements.

Roles and personas

Decision makers: VP Engineering, CTO, Head of AppSec, Engineering Managers
End users: software engineers, tech leads, security engineers

Pain points addressed

Limited internal review capacity
Need for senior-level feedback to reduce defects and technical debt
Desire to move security feedback earlier in the SDLC

05The pitch

What the product does (objective value proposition)

PullRequest (now branded as **HackerOne Code**) is a code-review-as-a-service offering: customers connect their source control systems (e.g., GitHub/GitLab/Bitbucket/Azure DevOps) and can request reviews from an external network of vetted engineers. The service combines AI-assisted risk prioritization and human review to provide feedback (bugs, maintainability, security issues) integrated into the developer workflow. PullRequest also offers adjacent services described as “Application Security Testing” and “Code Security Audit,” covering both ongoing PR review and point-in-time audit engagements.

Target market and positioning

Positioning is primarily B2B for engineering teams that:

lack internal review bandwidth,
seek faster PR turnaround,
aim to shift security feedback earlier in development.

The vendor states fit from small startups to very large enterprises. Recent messaging emphasizes security and a combination of automated prioritization with human review, indicating a shift from pure quality review toward AppSec / secure SDLC positioning after acquisition.

Get a comprehensive analysis of PullRequest including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 2, 2026

01Common complaints

You need low-cost, always-on scanning across every repo/PR: automated tools like GitHub Code Security, Semgrep, or Codacy are typically more cost-effective and consistent at scale.
You cannot grant third-party reviewers access to proprietary source code: even with NDAs and on-prem options, some organizations will not pass vendor risk review.
Your bottleneck is not code review capacity: if merges are blocked by product decisions, unclear requirements, flaky CI, or large PR sizes, adding external reviewers may not materially improve throughput.
You require publicly documented compliance certifications (e.g., SOC 2 Type II) before procurement: lack of publicly available certification evidence may delay procurement until documentation is provided under NDA.

Deal disqualifiers (poor fit)

Organizations that cannot allow third-party access to source code for policy or compliance reasons
Organizations that require 100% PR coverage but cannot contract for it
Teams primarily needing automated SAST/SCA rather than human guidance

Product limitations explicitly indicated or implied

Partial PR coverage under Smart Review Selection (30–40% typical as stated by the vendor) may not match buyer expectations for full coverage.
Review turnaround is typically bounded by vendor business hours (the vendor notes reviews are typically completed during US business hours; turnaround varies by review size and complexity).

Vendor-acknowledged security/operational constraints

Vendor documentation indicates backups do not regularly include repository data and that code can be deleted from their systems subject to backup retention caveats.
External reviewers access the code being reviewed; the vendor provides file anonymization/exclusion options via pullrequest.yaml (vendor statement).

Roadmap

No concrete public roadmap dates were captured in the provided sources.

02Why they buy

Differentiators supported by available evidence

Human review as a core differentiator versus purely automated tools (vendor positioning and post-acquisition materials).
Integrations with common SCMs (GitHub/GitLab/Bitbucket/Azure DevOps) to surface reviewer feedback in existing workflows (vendor statements).
On-premise options for certain Enterprise customers and SCMs (vendor statements).

Where competitors may be stronger

Automated tools typically provide broader continuous coverage, standardized policies, and ecosystem integrations for CI/CD and compliance reporting.
GitHub-native solutions reduce vendor sprawl if an organization is already standardized on GitHub.

03Field reports

What’s available (limitations)

The vendor site includes curated on-site testimonials from executive users; these are marketing references and are not independently verified in the captured sources.

Vendor-published testimonials (not independently verified)

Examples from the vendor homepage include:

Engineering leadership at a major automotive company describes the service as providing feedback they consider high quality and actionable.
A customer testimonial states the service caught issues before release.

These statements are vendor-published and do not include methodology or audit details.

Community mentions (limited specificity)

A community comment reported a positive anecdote about an external reviewer providing a good code review. This is an isolated comment without broader context (team size, plan tier, or timeframe).

Negative/critical feedback signals found

Why customers choose it (inferred from positioning and available evidence)

Based on product messaging and press coverage, reasons include:

External reviewer capacity to reduce internal review bottlenecks
Security vulnerabilities identified earlier in development
Integrations that surface feedback within SCM workflows

Why some customers might leave (inference; limited direct evidence)

Inferred churn reasons include:

Cost at scale (seat-based, annual billing)
Preference for automated SAST/SCA tools that scan continuously on every PR
Security or compliance constraints around granting external access to proprietary source code

Available case study-like evidence

Practical buyer takeaway

Treat vendor-published metrics as hypotheses to validate via:

A pilot with pre/post metrics (PR cycle time, defect escape rate, security issues found in CI/CD vs post-release)
Measuring reviewer acceptance rates and developer satisfaction through surveys

04Best fit

Company size

Likely best fit:

20–500 engineers where internal reviewer bandwidth is constrained and the codebase complexity may justify a higher-cost service.
Smaller startups can benefit, but the seat price may be a larger portion of budget.

Industries

Potential fits:

SaaS, fintech, healthtech, and other environments where security and fast iteration are important.
Regulated industries if on-premise or SSO options meet vendor risk requirements.

Roles and personas

Decision makers: VP Engineering, CTO, Head of AppSec, Engineering Managers
End users: software engineers, tech leads, security engineers

Pain points addressed

Limited internal review capacity
Need for senior-level feedback to reduce defects and technical debt
Desire to move security feedback earlier in the SDLC

05The pitch

What the product does (objective value proposition)

PullRequest (now branded as HackerOne Code) is a code-review-as-a-service offering: customers connect their source control systems (e.g., GitHub/GitLab/Bitbucket/Azure DevOps) and can request reviews from an external network of vetted engineers. The service combines AI-assisted risk prioritization and human review to provide feedback (bugs, maintainability, security issues) integrated into the developer workflow.

PullRequest also offers adjacent services described as “Application Security Testing” and “Code Security Audit,” covering both ongoing PR review and point-in-time audit engagements.

Target market and positioning

Positioning is primarily B2B for engineering teams that:

lack internal review bandwidth,
seek faster PR turnaround,
aim to shift security feedback earlier in development.

Get a comprehensive analysis of PullRequest including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →