> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mergeguide.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ROI methodology

> How MergeGuide estimates the engineer-hours you save by catching findings before merge.

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

| Severity     | Hours saved per pre-merge finding |
| ------------ | --------------------------------- |
| **Critical** | 6                                 |
| **High**     | 3                                 |
| **Medium**   | 1.5                               |
| **Low**      | 0.5                               |

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

| Source                                                                       | Year |
| ---------------------------------------------------------------------------- | ---- |
| IBM Systems Sciences Institute (via Boehm, *Software Engineering Economics*) | 1981 |
| NIST Planning Report 02-3 (Tassey, RTI International)                        | 2002 |
| Veracode State of Software Security v14                                      | 2023 |
| Ponemon / ServiceNow State of Vulnerability Response                         | 2023 |
| OWASP Application Security Verification Standard (ASVS)                      | —    |

## 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

<CardGroup cols={2}>
  <Card title="Dashboard" icon="gauge" href="/navigation/dashboard">
    Where the estimate appears.
  </Card>

  <Card title="PolicyMerge savings" icon="layer-group" href="/methodology/policymerge">
    How the compliance savings estimate works.
  </Card>
</CardGroup>