Every calculator on your product surface is either a moat you own or plumbing that owns your roadmap.
Fintech, wealthtech, and insurtech roadmaps carry the same set of stalled tickets: the retirement projector, the payoff planner, the coverage-timing tool, the tax-projection widget. They stall because the math is easy to start and expensive to finish, and because the decision that would have prevented the stall was never made. That decision is upstream of the ticket: is this calculator our differentiator, or is it table stakes we have decided to build anyway?
The wizard below is built to be answered in a planning room. It is not a rubric that produces a certificate. It is a forcing function that surfaces the reason a calculator is on the roadmap in the first place. Score honestly. Then read the interpretation. Then, if the score is not what the team expected, have the conversation the team has been avoiding.
The eight questions
Q1. Does this calculator embody proprietary intellectual property — a scoring model, an in-house methodology, a signature philosophy that the firm markets as its own? A yes here means the calculator is the product, not the plumbing. Score plus two for yes, zero for no.
Q2. Would three competitors' versions of this calculator produce the same output on the same inputs, within a few percent? Amortization schedules, contribution-limit calculators, refinance break-even tools all fail this test — they converge on the same answer because the underlying regulation admits only one right answer. Score minus two for yes, plus one for no.
Q3. Do the underlying constants — tax figures, actuarial factors, contribution limits — change at least annually? Constants that move impose a maintenance calendar the team either owns forever or externalizes. Score minus one for yes, zero for no.
Q4. Is the calculator visible to end users as a named feature, or is it internal plumbing that supports something else? A named feature has brand exposure; plumbing does not. Named feature plus one; plumbing minus one.
Q5. Would a customer reasonably ask for the formula behind the number? If yes, the calculator is subject to defensibility pressure that a homegrown implementation is poorly positioned to answer. Score minus one for yes, zero for no.
Q6. Does the calculator require domain expertise that your team has and competitors do not? A team with actuarial credentials shipping a life-insurance model has a moat; a general engineering team shipping the same model does not. Score plus two for yes, minus one for no.
Q7. Have you already shipped a version of this calculator once and are considering a rewrite? A rewrite of a calculator is the strongest signal that the original was not the moat the team believed it was. Score minus two for yes, zero for no.
Q8. Would replacing this calculator with an embedded, verified equivalent free at least one engineer-quarter per year for other work? The opportunity cost of building calculator maintenance is invisible in every roadmap that includes calculator maintenance. Score minus one for yes, zero for no.
- Q1. Proprietary IP: yes +2 / no 0
- Q2. Competitors converge on the same answer: yes -2 / no +1
- Q3. Constants move at least annually: yes -1 / no 0
- Q4. Named feature vs. plumbing: named +1 / plumbing -1
- Q5. Customer would ask for the formula: yes -1 / no 0
- Q6. Requires domain expertise you have and competitors do not: yes +2 / no -1
- Q7. Considering a rewrite: yes -2 / no 0
- Q8. Embedding would free at least one engineer-quarter: yes -1 / no 0
Interpretation
A score of plus four or higher indicates a moat. Build it. Staff it. Publish the methodology as part of the brand. The calculator is the product, and the maintenance calendar is the price of admission.
A score between zero and plus three indicates a contested case. Some of the calculator is differentiator, some is commodity. The typical resolution is to embed the commodity math and keep the top layer — the scoring, the ranking, the client-specific narrative — in-house. This is the most common outcome for wealthtech and insurtech products; the underlying computation is standard, and the value is in what the product does with the number.
A score of minus one or lower indicates table stakes. Embed. The engineering hours are not the point; the roadmap opportunity cost is. Every quarter spent maintaining a calculator that ten competitors also maintain is a quarter that did not ship the thing the ten competitors cannot copy.
| Score | Verdict | Action |
|---|---|---|
| +4 or higher | Moat | Build. Staff. Publish the methodology. |
| 0 to +3 | Contested | Embed the commodity layer. Reserve the top layer for in-house build. |
| -1 or lower | Table stakes | Embed. The roadmap you free up is the moat. |
The most expensive mistake
The most expensive mistake in this category is building a category-standard calculator — mortgage amortization, Social Security timing, refinance break-even — as if it were a moat. It is not one. The user cannot tell the amortization schedule apart from any other bank's amortization schedule, because there is only one right amortization schedule for a given set of inputs. The maintenance burden compounds every January. And the engineering team that built it is unavailable to build the thing that would actually differentiate the product.
“Your moat was never going to be a calculator. It is going to be everything you built while other teams rewrote theirs.”
Using the wizard in a real planning session
The wizard is designed to be answered in a room, in about twenty minutes, by a product manager, an engineering lead, and a compliance representative. The score is not the deliverable; the argument that produced the score is. If the room cannot agree on whether Q1 is a yes, that disagreement is the finding. Resolve it before writing another line of code.
The output of the exercise is not always an embed. Sometimes the score is plus five and the team commits to a real build. That is a valid outcome. The wizard exists to prevent the other outcome — the two-year rebuild of something the team never should have owned in the first place.
A note on hybrid outcomes
Most real answers are hybrid. A wealth-management product might score plus four on its proprietary tax-loss-harvesting model and minus three on its underlying amortization schedule. Both are correct. The hybrid answer is to embed the amortization and build the harvesting logic on top of it, using the amortization output as an input to the harvesting model. The wizard is designed to be run per calculator, not per product. A product with eight customer-facing calculators will typically end with three to five embedded and the rest built. That distribution is healthier than the two extremes the wizard exists to prevent — every calculator built, or every calculator embedded.