A calculator ships when the list is done. The list exists because every item that gets skipped shows up later as a support ticket, a compliance memo, or a correction.
A financial calculator has a lot of moving parts that are not the arithmetic. The arithmetic is often the easiest part to get right. The infrastructure around the arithmetic — validation, error messages, attribution, storage, monitoring, review sign-off — is where launches go slower than expected and where post-launch incidents are most likely to originate. This checklist is the working list a team should complete before flipping a calculator to production. It is organized by owner because the largest source of delay is cross-team dependencies that were not scoped until the day someone tried to ship.
Product owner
- Scope statement: one sentence naming the specific question the calculator answers.
- Audience: the specific user the calculator is designed for, in one clause.
- Inputs list: every input the user supplies, with the label the UI will show.
- Outputs list: every value the UI displays, with the label the UI will show.
- Assumptions statement: the plain-language version of what the calculator does not consider.
- Success metric: how the team will know the calculator is being used.
- Rollout plan: whether the calculator ships to all users or a subset first.
Engineering owner
- Model spec URL: linked from the code that invokes the model.
- Version pinning: the specVersion the integration currently targets, stored in configuration not code.
- Error handling: every out-of-domain input produces a user-facing message the copy team wrote.
- Sentinel handling: infinity, never-reached, and other sentinel outputs render as intended, never as raw strings.
- Envelope storage: response envelopes are persisted for the retention window the compliance team approved.
- Hash verification: at least one automated test recomputes the record.sha256 against a stored fixture on every build.
- Rate-limit posture: the integration respects the vendor’s per-IP limits and degrades gracefully when a limit is hit.
- Latency budget: the p95 render time is measured and within the target the product team agreed to.
Compliance owner
- Disclosure copy: a compliance-approved sentence appears near the primary output.
- Assumptions surface: the model’s assumptions are visible or one click away, not buried in a footer.
- Facts panel: the constants used are displayed with periods and source names, not just values.
- Recordkeeping: the storage window matches the applicable regulation for the calculator’s use case.
- Attribution: the vendor’s attribution requirements, if applicable, are implemented per the vendor’s pricing terms.
- Review sign-off: a named reviewer has approved the calculator before launch, with the sign-off dated and stored.
- Change log entry: the launch is recorded internally in a way that surfaces for future audits.
Marketing owner
- Placement: the calculator lives on a page whose surrounding content prepares the user to interpret the result.
- Traffic plan: a specific plan for how the first users reach the calculator, not a hope.
- Related content: at least one adjacent article the user can read after receiving the answer.
- Analytics: page-level and interaction-level analytics are wired before launch, not after.
- Feedback channel: the user has a way to report a wrong number or a confusing label without opening a support ticket.
Support and content owner
- FAQ: the three most likely user questions have written answers stored where support can find them.
- Escalation path: a named person owns questions the FAQ does not resolve, with a response-time expectation.
- Screenshots: pre-launch screenshots are archived so post-launch regressions can be diffed against them.
- Editorial copy: labels, placeholders, and error messages have all been read by an editor, not only by an engineer.
The launch review
- Every item above is checked and dated.
- The team has agreed which items would trigger a rollback if they failed post-launch.
- The rollback plan is written and someone knows how to execute it.
- The launch date is chosen with the maintenance calendar in mind (avoid launching a tax-touching calculator the week before an IRS publication window).
Post-launch
- Twenty-four hour check: latency, error rate, and first user interactions reviewed by the product owner.
- Seven-day check: analytics against the success metric, user feedback triaged, any hotfixes shipped.
- Thirty-day check: the calculator is compared against a primary source for at least one representative input; the result is dated and stored.
- Annual review calendar: an entry is added for the same date next year to revisit constants and assumptions.
The checklist looks long because launches that were not caught up in the list produced the items on it. Every item is here because skipping it has a specific, predictable failure mode. Teams working through the list for the first time typically find that they are already doing half of it implicitly and simply had not written it down; the value of the list is not the items the team is already doing, it is the items the team is not.
Why the list is organized by owner
Cross-team dependencies are the most common source of launch delay in practice. Engineering waits on compliance sign-off. Compliance waits on the assumptions surface the product team was supposed to draft. Product waits on the analytics wiring the engineering team was supposed to add. Nobody in any single team is blocking the launch; the launch is blocked by items nobody owned. Organizing the checklist by owner surfaces the ownership problem before the launch is imminent, when there is still time to reassign an unowned item without moving the ship date.
A common failure mode is to treat the checklist as an engineering artifact and let engineering owners work through it alone. This produces a checklist walkthrough in which engineering items pass and non-engineering items are checked because engineering assumes another team is handling them. The check does not verify that another team has actually handled the item; it verifies that engineering does not need to. The remedy is to require a named owner beside every checked item, from the team responsible for that item; anything less is a checklist that fails at the launch review.
The launch review meeting
The final gate before flipping the calculator to production is the launch review meeting. The meeting is short by design; every item on the checklist is either checked or explicitly deferred with a named reason. Items that are deferred without a named reason cause the meeting to stop, and the ship date moves. This posture is stricter than most teams start with, and it produces launches that do not have to be rolled back. Teams that treat the meeting as a formality find that formality tolerates gaps; teams that treat it as a real gate produce ships that hold up under post-launch scrutiny.
The reviewer at the launch meeting is someone senior enough to say no. If the reviewer is a peer who feels social pressure to approve, the meeting is theater. A named reviewer with the authority to hold a launch is not a bottleneck; the reviewer is what makes the checklist mean something. Teams that skip this appointment find that the checklist becomes a formality within two or three launches; teams that keep it in place find that the checklist keeps improving because the reviewer keeps finding the same gaps and pushing them into the pack-level layer.
Post-launch discipline
The launch is not the end of the checklist. The three post-launch checks — twenty-four hour, seven-day, thirty-day — are what turn a launch from an event into a durable ship. Each check has a specific owner, and each check produces a small written note stored where later maintenance can find it. Calculators that shipped through this discipline are the ones that a compliance reviewer years later can trace back to a specific launch date, a specific approved state, and a specific set of decisions the team made. That trace is what audit-ready means in practice, and it starts at the launch review.
The annual review calendar entry is the item most teams skip and the item that pays back the most. Calculators live in production for years; regulatory constants move, edge cases surface, team members turn over. A calendar entry that fires on the same date next year, addressed to whichever team member is on the calculator at that point, is what prevents the calculator from becoming an orphan. The entry costs a minute to create at launch and prevents the kind of quiet drift that only shows up when a user or a reviewer asks a specific question three years later.
“The list is what a shipped calculator looks like when nothing was skipped. Every skipped item is a support ticket waiting.”
How to use the checklist across a portfolio
A team shipping one calculator can walk the list in a single meeting. A team shipping a family of calculators — the mortgage decisions pack, the retirement pack, the equity-compensation pack — can walk it once and then use a shorter delta list for subsequent pack members. Items that are pack-level (attribution posture, envelope storage schema, disclosure copy patterns) get resolved once. Items that are calculator-level (inputs list, outputs list, primary-source verification) are the delta list for each new calculator. Teams that separate the two lists ship the second, third, and fourth calculators materially faster than the first, without cutting any of the items.
Sources
- [1] Six Answers a Financial UI Should Be Able to Give. https://worthune.com/writing/six-answers
- [2] The Glass Box Principle. https://worthune.com/writing/glass-box-principle