The buy-vs-build question is answerable. The reason it usually is not answered is that one side of the ledger is left off.
The typical buy-vs-build debate compares a vendor's price to a build cost that omits maintenance, testing, compliance review, and opportunity cost. The vendor wins the technical argument and loses the meeting because the build number was wrong by half. This worksheet makes both sides of the ledger visible. It produces a defensible dollar figure on each side and a break-even year. The point is not to make the buy side win; the point is to make both sides visible.
Inputs to gather
A fully-loaded engineer cost per year. Salary alone is not the number; the working multiplier is 1.3 to 1.5, covering benefits, employer taxes, equipment, software, and allocated overhead. If the finance team publishes a fully-loaded rate for internal use, use that. If not, apply the multiplier and note the assumption. This is the single number that most changes the outcome; underestimating it is why most build-side estimates are half of reality.
Estimated engineer-months for the initial build. Most teams undercount here by a factor of two. The estimate should include time for the model itself, the input validation, the error handling, the API surface, the test suite, the observability wiring, and the first pass through compliance review. If any of those is missing from the estimate, the estimate is not comparable to a vendor's price.
Annual maintenance load in engineer-months. This is the constant-update work, the edge-case fixes, the dependency churn, and the tax-year rollover. A reasonable planning band is one and a half to four engineer-months per year per calculator — an estimate to be replaced by your own history where you have it. The band widens for calculators with more constant dependencies (retirement, Social Security) and narrows for calculators with fewer (basic amortization).
Compliance review hours per calculator per year, at the loaded compliance-team rate. This is often omitted from build-side estimates because compliance is not part of the engineering budget. It is still a real cost. A calculator that requires ten hours of compliance review per year at a fully-loaded compliance rate of two hundred dollars an hour is a two-thousand-dollar recurring line item that never appears in the engineering ledger.
QA and test-authoring load per calculator per year. Verification cases do not write themselves. A test suite that keeps a calculator honest requires ongoing investment as edge cases surface. Include the QA cost explicitly; a build-side estimate that treats QA as free is a build-side estimate that will disappoint in year two.
Opportunity cost. This is the largest line item and the hardest to quantify. If the calculator work is being done by the engineer who would otherwise be building the thing the product is differentiated by, the opportunity cost equals the delayed revenue or delayed strategic value of that feature. If the engineer would otherwise be idle, the opportunity cost is zero. The honest answer is almost always closer to the first case than the second.
Liability surface. This is expected annual cost of a customer-facing correctness incident — probability of an incident times remediation cost. Remediation includes not just the fix but the disclosure, the customer communication, the regulatory notification if applicable, and the reputational recovery. For most consumer-facing financial calculators, a modest annual expected value in this line item is defensible; treating it as zero is not.
- Fully-loaded engineer cost per year.
- Initial engineer-months for build (× 1.5–2 for honest estimate).
- Annual maintenance in engineer-months.
- Compliance review hours per year.
- QA / test-authoring load per year.
- Opportunity cost — what the engineer would otherwise ship.
- Liability surface — probability × remediation cost.
The formula
The break-even year is the smallest N for which the buy side cost through year N is less than or equal to the build side cost through year N.
build_cost(N) = initial_engineer_months × loaded_monthly_cost + N × (maintenance_months × loaded_monthly_cost + compliance_hours × loaded_hourly_compliance + qa_months × loaded_monthly_cost + opportunity_cost_per_year + expected_liability_per_year)
Compare to buy_cost(N) = N × annual_vendor_cost. Break-even year is the smallest N where buy_cost(N) ≤ build_cost(N).
Typical outputs
The numbers below are planning ranges, not benchmarks or observed data. Every situation differs; plug in your own figures. The ranges exist to sanity-check estimates that come in dramatically outside them.
| Line item | Typical low | Typical high |
|---|---|---|
| Initial build (engineer-months) | 3 | 9 |
| Annual maintenance (engineer-months) | 1.5 | 4 |
| Annual compliance review (hours) | 10 | 60 |
| Annual QA / test authoring (engineer-months) | 0.5 | 2 |
| Expected annual liability surface | Low if internal-only | Materially higher if customer-facing |
A calculator scoped honestly with these ranges — even at the low end — produces a build cost that competes with a mid-tier vendor contract within eighteen months. At the high end, the break-even is under a year. The reason build estimates come in lower than these ranges is not that the calculator is easier than described; it is that the estimate is leaving line items off.
“Buy-vs-build is not close when the build side of the ledger is honest.”
Presenting the worksheet
The worksheet is designed to be filled in a one-hour meeting with a product lead, an engineering lead, and a finance representative. The output is a two-column table and a single number: the break-even year. Present the output as-is. Do not adjust to make either side look better. If the finance representative disputes the loaded engineer rate, use theirs; if the engineering lead disputes the maintenance estimate, use theirs; the point of the exercise is to produce a number the room agrees on.
A room that cannot agree on the inputs has not yet done the work of understanding what building the calculator would actually cost. Producing that agreement is the deliverable, whether or not it changes the decision.
Two sensitivity checks to run before the meeting ends
First, halve the vendor cost and re-run. If the buy side still wins at half the vendor's price, the decision is robust to pricing risk — a Pro-tier increase, an SLA upgrade, an enterprise renegotiation. If the buy side loses at half, the build case depends on the vendor being cheap, which is a fragile assumption and worth naming out loud.
Second, double the initial build estimate and halve the maintenance estimate. If the buy side still wins, the decision is robust to build-side optimism. If it loses, the build case depends on the team executing better than industry median, which is not an assumption that survives contact with a real quarter. Both sensitivity checks take five minutes and prevent the kind of decision that gets revisited eighteen months later when the numbers turn out to have been wrong in the direction everyone quietly expected.