Pricing

Pricing for teams that want build truth and bug-focused review on every Java PR.

prmerger is rolled out based on repository shape, PR volume, and support needs. The product is intentionally scoped around protected Java pull requests rather than generic seat-based automation.

Plan

Starter pilot

Custom

Best for one or two repositories getting their first Java PR guardrail in place.

  • Single-team rollout
  • Maven or Gradle policy setup
  • PR review comments on bug-prone changes
  • Build and unit test merge blocking
Request pricing
Most common

Team rollout

Custom

Designed for engineering teams that want prmerger protecting several active Java services.

  • Multiple repositories or modules
  • Shared review policy across teams
  • Onboarding help for branch protection
  • Priority support during rollout
Request pricing
Plan

Enterprise

Custom

For larger Java organizations that need broader repository coverage and operational support.

  • Organization-wide rollout planning
  • Monorepo and multi-service policy design
  • Custom review and escalation workflows
  • Dedicated implementation support
Request pricing
How Pricing Works

We scope the rollout around your repositories, not generic credits.

  • Pricing depends on repository count, PR volume, and the level of rollout support you need.
  • Every plan focuses on one outcome: no merges through failing Maven or Gradle builds, failing unit tests, or unresolved critical review findings.
  • If your build commands are unusual or repo topology is complex, we scope that during onboarding rather than forcing a generic plan shape.
Included In Every Rollout

The core product stays the same.

Build-aware verdicts

Merge decisions are tied directly to the Maven or Gradle command you configure.

Unit test enforcement

Broken suites stay visible on the PR until the branch turns green again.

AI review comments

Review notes target bug risk and missing coverage instead of generic formatting noise.

Branch protection fit

The rollout is designed to work alongside the merge rules your GitHub workflow already uses.

FAQ

Questions teams ask before rollout.

Is there a self-serve free tier?

This build is positioned around guided Java team rollouts, so pricing is currently handled through a contact-led setup.

What affects pricing the most?

Repository count, concurrent PR volume, and how much implementation support your team wants during rollout tend to matter most.

Can we start with one repository?

Yes. Many teams pilot prmerger in a single Java service, tune the review policy, and then expand to additional repositories.