The Two-Month Build That Became an Afternoon

The two-month calculator project has always been the same two months. The question is whether you keep spending them.

Most engineering organizations that have shipped a financial product have, at some point, put a calculator on their roadmap and watched it slide. The pattern is old enough to be predictable. A product manager scopes a retirement projection or a refinance widget as a two-week task. Engineering estimates two months once the edge cases are known. QA raises the estimate again once the constants surface. Compliance adds a review cycle. The calculator ships at the end of a quarter that started with something else on it, or it does not ship, and the roadmap slot converts into a permanent line item nobody names.

The specific work in that two months is not the math. The math is a few equations and a handful of if-statements. The two months is what surrounds the math: input validation, error messages, contribution-limit lookups, edge-case handling, unit tests, integration tests, compliance review, monitoring, release process. Every one of these items is legitimate. Every one of them is also identical to the work another team did last year on a nearly identical calculator at a nearly identical company. The engineering hours are not producing something the company owns uniquely; they are reproducing something the industry has already produced dozens of times.

What embedding replaces

The verified-model approach externalizes the calculator layer. The math still runs; it runs on someone else’s server, against a maintained spec, with constants read from a maintained registry. The caller’s integration is a POST request, an input validation the API performs before computing, a response envelope the UI displays, and a stored record for later audit. What was two months of engineering becomes an afternoon of wiring, and the wiring is generally the sort of task a mid-level engineer can complete without a specification meeting.

The externalization is not a philosophical claim; it is a specific reallocation of engineering hours. Hours that used to go into contribution-limit lookup logic go into UI patterns above the API. Hours that went into edge-case triage go into product features that differentiate the caller. Hours that went into annual constant updates go into whatever the team wanted to ship this January. None of these hours vanish; they move from work the industry has done many times to work only this team can do.

The specific work that stops

• ✓Reading each fall's IRS revenue procedures and notices (and the spring HSA revenue procedure) and translating them into code changes.
• ✓Maintaining a QA suite whose failure cases are variations on 'the tax rule moved and we did not notice.'
• ✓Reviewing each shipped calculator with compliance annually to confirm it still reflects current law.
• ✓Debugging correctness incidents where a customer noticed a stale value before the team did.
• ✓Writing runbooks for what to do when a constant changes mid-year.
• ✓Onboarding new engineers to a codebase whose regulatory context they have to learn from scratch.

None of these tasks is glamorous. Each of them recurs. Together they consume more engineering capacity than most teams account for when they estimate calculator work, because the work is not visible on the day it is scoped; it emerges over the years the calculator lives in production.

What the freed capacity is worth

The value of the reclaimed engineering capacity depends on what the team ships instead. A team that reclaims a quarter and uses it to ship the next feature its competitors do not have has captured the value. A team that reclaims a quarter and absorbs it into general velocity has captured something smaller but still real: a lower baseline of hidden work, which improves morale and retention alongside output.

The most useful framing is opportunity cost. The engineer who would have spent Q1 rewriting the retirement calculator instead spends Q1 on the thing the company is genuinely differentiated by. If that thing exists on the roadmap, the trade is clear. If it does not, the calculator work was hiding a strategic gap the company should address regardless of the buy-versus-build decision. Either way, the trade surfaces information the team did not have before.

“The math was never the moat. The engineering time it consumed was hiding what the moat could have been.”

Where the trade does not close

Some calculators are genuine intellectual property. A scoring model, an in-house methodology, a signature philosophy that a firm markets as its own — these belong homegrown. Table Stakes vs. Moat: Deciding What to Build In-House (/writing/table-stakes-vs-moat) is the framework for making that determination per calculator. The answer for most calculators on most product surfaces is that they are table stakes; the answer for a small minority is that they are moats. Both answers are legitimate; the value of the wizard is that it produces the specific determination rather than defaulting to build.

The trade also does not close instantly. A calculator already in production requires migration, not a rewrite. Callers who plan the migration well decommission the homegrown calculator on a schedule the team owns rather than a schedule an incident forces. The Buy-vs-Build Worksheet for Financial Calculators (/writing/buy-vs-build-worksheet) produces the specific dollar figure a migration is worth; the honest version of that ledger is what closes the trade in most cases.

The pattern engineering leaders recognize

Engineering leaders who have shipped several financial products recognize the pattern this piece describes. The first calculator is the two-month project that runs long. Each additional calculator drags the maintenance calendar for the ones before it behind it. A few calculators in, the team is running a small internal financial-math function that nobody planned for. This is the point at which engineering leaders tend to start looking for a way to externalize the layer.

The recognition is not a criticism of the teams that built the internal organizations. Ten years ago, externalization was not available; the choice was to build the layer or not ship the product. Today the choice is different. Leaders who came up building the layer and have not revisited the decision are working from an assumption that the environment has moved past.

What the afternoon actually looks like

The concrete integration is a POST request. Inputs go in, an envelope comes back with the outputs, the spec version, the assumptions, the facts referenced, and a record. The UI reads the envelope and displays the outputs; the stored envelope goes to a database column. The specific engineering time to do this against a well-documented API for a straightforward model is generally a few hours, plus whatever time is needed to design the UI around the outputs. That last part is where the meaningful engineering time now lives, and it is the part the team is genuinely differentiated on.

The point of the essay

Engineering leaders reading this piece are not being asked to make the buy-versus-build decision from an essay. The decision is per-product, per-calculator, per-team. What the essay is asking is that the decision get made explicitly rather than by default. Every calculator on the roadmap has an implicit answer to the question. Most implicit answers were made a decade ago in a different environment. Making the answer explicit is an afternoon of thought that has the same character as the afternoon of engineering the externalized approach would produce: small, specific, and disproportionately worth doing.