ROI methodology

The dashboard surfaces an estimate of engineer-hours saved by catching findings at pull-request time instead of letting them reach production. This page explains exactly how that estimate is calculated, so you can audit the math and compare it against your own data.

​

The estimate in one line

Each finding MergeGuide catches before merge is counted as a finding not triaged, reproduced, or remediated in production. We credit a conservative number of hours saved per pre-merge finding, by severity, and sum across your findings.

​

Hours credited per finding

Total estimated hours saved is the sum across your findings of (count at each severity × hours for that severity).

​

Where the numbers come from

The figures combine two published anchors:

1. The phase-cost multiplier — defects found after release cost substantially more to fix than defects found before. The IBM Systems Sciences Institute data (via Boehm, Software Engineering Economics, 1981) and the NIST Planning Report 02-3 (Tassey, 2002) put the post-release multiplier in the range of roughly 5×–30×. We apply the low end (5×) so the estimate is hard to overstate.
2. Median pre-merge engineer-fix time — drawn from the Veracode State of Software Security v14 (2023) and the Ponemon / ServiceNow State of Vulnerability Response (2023).

We round downward throughout. A defensible underestimate is better than an indefensible overestimate.

​

Published sources

​

What the estimate excludes

• Post-incident costs — customer communication, audit, breach notification, and regulator disclosure are not included.
• False positives — only findings you fixed or acknowledged as true positives count. Suppressed and dismissed findings are excluded.
• Customer-specific promises — the figure is a general, industry-grounded heuristic, not a guarantee of your organization’s results. Compare it against your own incident-response and cycle-time data.

​

Next steps