Fire. Wheel. Retirement planner. The joke on the homepage is a joke because everyone in the room has lived it.
Financial software has been building calculators for four decades. The technology stack has changed on a predictable cadence — mainframe, spreadsheet, thick client, web, mobile, chat. The calculators have not. Mortgage amortization, retirement projection, Roth-versus-traditional break-even, term-life needs analysis, refinance break-even, college savings, debt payoff. Each generation of tooling rebuilds the same short list. Each generation runs into the same failure mode. The failure mode is not a technology problem. It is a shape-of-work problem, and it survives every stack change because the stack was never the issue.
The pattern, by era
The spreadsheet era, the nineteen-eighties into the mid nineteen-nineties. Calculators lived in Lotus 1-2-3 and, later, Excel files on advisors' desktops. Constants were typed in by hand each January. Errors were individual, private, and unaudited. An advisor who mis-keyed a bend point produced wrong projections for every client that year, and nobody outside that advisor's office ever knew. The maintenance model was one person per spreadsheet, forever.
The thick-client era, the mid nineteen-nineties into the mid two-thousands. Calculators shipped as compiled binaries in advisor software. Updates arrived on CD-ROM, then on installer downloads. A tax-year change meant a shipping cycle — build, QA, package, mail. The advisor received the update in February and installed it in April, meaning three months of client meetings used last year's numbers. The maintenance model was one release train per calculator, run by an engineering team that treated the calculators as a maintenance burden and the trading platform as the product.
The web era, the mid two-thousands into the mid twenty-tens. Calculators became HTML forms with server-side math. Constants lived in a database table nobody documented. When the developer who wrote it left, the tribal knowledge left too. The maintenance model was whichever engineer picked up the ticket, plus a hopeful comment in the code that read TODO: verify against IRS pub 590. The comment was still there five years later.
The mobile and API era, the mid twenty-tens into the early twenty-twenties. Calculators were re-implemented per platform — iOS, Android, web, sometimes a partner-white-label edition. Three implementations, three sets of bugs, one product manager reconciling screenshots. The mobile team believed the web team's math; the web team believed the API team's math; the API team was two contractors ago. Constants were now in three places and diverged whenever any one of them was updated in isolation.
The LLM era, the early twenty-twenties onward. Calculators are increasingly replaced by chat prompts that guess numbers. The delivery surface improved dramatically; the correctness surface regressed. A user asking a chat product for a Roth contribution limit now gets an answer with confident cadence and no citation, produced by a model whose training data is dated and whose arithmetic is probabilistic. The old failure modes returned in a new interface, with better prose and worse math.
1980s — Spreadsheet
Calculators on advisors' desktops. Constants typed by hand. Errors private and unaudited.
1990s — Thick client
Calculators shipped on CD-ROM. Tax-year updates arrived on a shipping cycle.
2000s — Web
HTML forms with server-side math. Constants in an undocumented DB table.
2010s — Mobile / API
Three implementations, three sets of bugs, one PM reconciling screenshots.
2020s — LLM
Chat prompts guess numbers. Old failure modes in a new interface.
The through-line
The pattern across eras is that each generation solved the delivery problem — CD-ROM to web to mobile to chat — and left the correctness problem untouched. The formula got copied. The constants got copied. The edge cases got rediscovered by whichever engineer picked up the ticket in the new stack. Nobody wrote down what was deliberately excluded, so the next team excluded different things, producing subtle behavior differences across implementations that nobody could reconcile without reading the code, which nobody had time to do.
The specific artifact that would have solved the correctness problem — a written spec, held apart from any implementation — was skipped in every generation, for the same reason. It felt like documentation. Documentation is what teams write after the code works, and by then the tribal knowledge has hardened into the code, and by the time the documentation project starts the person who understood the assumptions has moved on. The result is code that computes something no living person can fully articulate.
“The calculators did not change. The teams rewriting them did.”
Why now
The verified-computation approach is not new because the math got harder. It is new because two things happened at once. First, the cost of shipping the same calculator for the fifth time — with a different edge-case profile each time — finally exceeded the cost of publishing one spec and pointing every implementation at it. Second, language models started needing something to cite, which turned the previously-optional spec into a load-bearing artifact for AI interfaces.
The first shift is economic. The second is architectural. Together they close the era of every product building the same calculators and open an era of shared, versioned, sourced computation that every product can invoke. The rendering interface changes — from HTML form to native mobile to chat — and the underlying computation stays the same, cited by version, with the constants pulled from a registry that updates against primary sources.
The end of the pattern
The pattern ends when the artifact — spec plus registry plus verification cases — becomes the shared object, and each generation of interface becomes a rendering of it. A retirement calculator on a web page, a retirement calculator in a mobile app, and a retirement calculator inside a chat assistant now share the same spec, the same constants, the same version, and the same audit envelope. If the spec updates, all three surfaces update together. If the spec has an ambiguity, all three surfaces surface it together. The bug that used to live in one implementation now lives in the spec, where it can be fixed once.
That is the shift this content library, and the product it describes, exist to argue for. The joke about fire, wheel, and retirement planner works because everyone in the room has shipped the retirement planner at least once. The next stack change is a chance to ship it for the last time.