Verified-Model API vs. Homegrown Calculator

The arithmetic is public. The comparison is about the artifacts that ship around it.

The choice between a verified-model API and a homegrown calculator is often framed as a build-versus-buy question, which flattens the interesting parts. Both approaches produce numbers on a screen. Both approaches can be correct today. The material difference is in what happens across time — as constants move, as edge cases surface, as a customer asks how the number was produced, as a compliance reviewer opens the codebase for the first time. The comparison below uses six dimensions that separate the two approaches by more than any single build-versus-buy figure captures.

Six dimensions

Time to first correct answer. A homegrown calculator that hits the happy path takes days to weeks. A homegrown calculator that also handles the edge cases documented in the batch-1 piece on hidden retirement-calculator costs takes months. A verified-model API returns an answer verified against a published spec on the first call, because the edge cases live in a shared spec that both implementations honor. The gap is largest where the underlying computation is standard and shrinks toward zero where the computation is genuinely novel.

Maintenance surface. Homegrown calculators carry a maintenance calendar the team owns forever. Contribution limits move. Regulatory factors move. Occasionally, entire regulatory regimes are repealed — the Windfall Elimination Provision and Government Pension Offset were both repealed by the Social Security Fairness Act in January 2025, retroactive to 2024, which every homegrown Social Security calculator maintained through that period had to react to.^[1] A verified-model API externalizes this calendar. The maintenance work still exists; it happens somewhere else.

Provability. Homegrown calculators typically produce numbers without a resolvable spec, a stored version, or a hash the caller can verify later. A verified-model API produces a response envelope that includes the model, the spec version, the inputs, the outputs, the assumptions, the facts referenced, and a SHA-256 record over model plus specVersion plus inputs plus outputs, key-sorted, canonical JSON. Provability is not marketing; it is a specific property of the response that either exists or does not.

Staffing model. Homegrown calculators require engineering, QA, and compliance-review capacity that scales with the number of calculators. A verified-model API concentrates that capacity in one vendor and lets the caller's team scale on the layer above — the UI, the sequencing logic, the product-specific narrative. The staffing question is not whether calculators need experts; it is whether the caller's product needs its own experts for standard computations.

Liability surface. A customer-facing correctness incident on a homegrown calculator is the caller's incident. On a verified-model API with a published spec, verified dispatch, and a stored envelope, the incident becomes reproducible: the caller can replay the stored inputs against the pinned spec version and confirm the SHA-256 record matches, or point at the changelog entry that explains a change. Liability does not disappear; it becomes traceable, which is a different kind of exposure than untraceable liability.

Extensibility. Homegrown calculators extend on the caller's timeline. A verified-model API extends on the vendor's timeline. The extensibility question is not which is faster in the abstract; it is which is faster for the specific extension the caller cares about. Callers whose extensions are standard financial computations are usually served better by the vendor's timeline. Callers whose extensions are proprietary methodology are served better by their own.

Where the comparison is genuinely close

Not every calculator sits cleanly on one side. Proprietary scoring models, in-house methodologies that a firm markets as its own, and computations that embed regulatory interpretations specific to a firm's business all belong homegrown. The batch-1 Table Stakes vs. Moat wizard is the tool for making that determination; the working guidance is that if the calculation would be the same at three competitors, it is table stakes.

The comparison is also close when the extension the caller needs is one the vendor's roadmap does not name. A caller who needs a jurisdiction-specific projection or an audience-specific framing that no shipping model produces should not wait indefinitely for one to appear. The honest answer is often composition: use the verified models for what they compute, and build the caller-specific layer on top.

“The arithmetic is not the moat. The artifacts around the arithmetic are what age well.”

What the comparison is not

The comparison is not a price sheet. Free tiers and paid tiers exist across the vendor market and the dollar figure is rarely the load-bearing input to the decision. The batch-1 Buy-vs-Build Worksheet frames the decision using engineer-months, maintenance load, compliance review hours, opportunity cost, and expected liability surface, all of which move by more than most vendor prices. A comparison that leads with price and ends with a break-even year usually finds that the pricing question is smaller than the operational question.

The comparison is also not a promise about correctness in the abstract. A verified-model API can be wrong. A homegrown calculator can be right. The dimensions above describe the shape of each approach; they do not certify either. What they establish is that when the approaches are wrong, the vendor approach is wrong in ways that surface at release time through verification cases, while the homegrown approach is wrong in ways that surface at a customer's return.

How to run the comparison in a real evaluation

The comparison is easier to run against specific calculators than against calculators in the abstract. Pick the two or three calculators the team is closest to shipping or maintaining, apply the six dimensions, and produce a per-calculator recommendation. The batch-1 pieces on Table Stakes vs. Moat and Buy-vs-Build produce the qualitative and quantitative sides of that per-calculator recommendation. Aggregate the recommendations at the product level; do not aggregate the abstract question at the platform level.

A dimension the framing sometimes hides

The six dimensions above are the ones a caller can score. A seventh, harder to score, is the shape of the team the calculator lives inside. A homegrown calculator inside a team that treats calculators as a specialty ages well; the team knows the primary sources, subscribes to the publication cadence, and revisits the code annually. A homegrown calculator inside a team that treats calculators as a chore ages badly; the code was written by an engineer who has moved on, the tests were skipped for time pressure, and the annual review is scheduled and rescheduled until it stops being scheduled. Both teams shipped the same calculator on day one. Their calculators are not the same object by year three.