Comparison
Build your own calculators, or license them?
Writing one financial calculator is about a week. Keeping a set of them correct is the actual job: contribution limits and brackets move every January, and a quiet error in a projection is the kind of bug users find before your tests do. Build when the math is your differentiator. License when you want it to be somebody else’s maintenance contract.
Below is a cost model with its assumptions in the open, and the arguments against buying stated plainly. We sell one of these two options, so read it accordingly.
Last reviewed
The assumptions, first
These are guesses, not findings. Nobody surveyed anyone, and there is no study behind them. They are here before the totals rather than in a footnote because the totals are worth exactly as much as you think these are.
| Assumption | Value | Why this figure |
|---|---|---|
| Fully-loaded engineer cost | 120 USD/hour | A round number for a mid-level US engineer including benefits and overhead. Replace it with yours; it scales everything below linearly. |
| Build the first model properly | 40 hours | Not the afternoon it takes to write the formula — the week it takes to agree what it computes, handle the edge cases, and write tests you would defend. |
| Each model after the first | 16 hours | Cheaper once the patterns exist, and this is the figure most likely to be too low if the models differ in kind rather than in inputs. |
| Annual constants update | 24 hours/year | Finding what changed in IRS and SSA figures, updating them, and re-checking what depended on them. Recurs every January whether or not it is anyone's job. |
| Regression fixes and drift | 20 hours/year | The bugs found after release. A guess, and the one teams dispute most — usually downward before they have shipped, upward afterwards. |
What that comes to
The arithmetic is deliberately simple and shown in full. The useful part is not the total — it is that two of the three lines never stop.
6 calculators
$19,680
first year, then $5,280 every year after
- $14,400 — Initial build
40 hours for the first model, 16 for each of the other 5 - $2,880 — Constants, every January, every year
24 hours a year, regardless of whether anything else changes - $2,400 — Regressions and drift, every year
20 hours a year of bugs found after release
12 calculators
$31,200
first year, then $5,280 every year after
- $25,920 — Initial build
40 hours for the first model, 16 for each of the other 11 - $2,880 — Constants, every January, every year
24 hours a year, regardless of whether anything else changes - $2,400 — Regressions and drift, every year
20 hours a year of bugs found after release
25 calculators
$56,160
first year, then $5,280 every year after
- $50,880 — Initial build
40 hours for the first model, 16 for each of the other 24 - $2,880 — Constants, every January, every year
24 hours a year, regardless of whether anything else changes - $2,400 — Regressions and drift, every year
20 hours a year of bugs found after release
For scale rather than as a recommendation: a year of Worthune Pro at the published rate is $2,388, which covers the full catalog. Whether that is the better trade depends on things this model cannot see — how much you have already built, how unusual your models are, and what your team would be doing with the time instead.
Read this part
Where this model is weakest, and where building wins
A build-versus-buy model published by the vendor being compared against is structurally suspect. Pretending otherwise would insult the reader, so the arguments that cut against us are on the page.
- This model is published by a vendor with an interest in the answer. Treat the shape as the useful part and replace every figure with your own.
- It counts only engineering time. It ignores that your team may already have most of this built, in which case the marginal cost of one more calculator is genuinely small.
- If the math is your differentiator — the thing your product is actually about — outsourcing it is the wrong call whatever the arithmetic says.
- Buying is not free of work: an integration is still an integration, and a dependency on a small vendor is a real risk you should price.
- Some teams build because they need something nobody sells. If your model is unusual enough, this comparison does not apply to you at all.
The option most teams miss
If you have already built your calculators, the question is not whether to replace them. It is whether you would find out if one of them drifted. Our eval datasets are deterministic input and expected-output pairs at the tolerances our own verification harness holds — run your engine against them in CI and the January constants change surfaces as a failing test rather than a support ticket.
Questions
Common questions
- Should we build our own financial calculators or license them?
- Building one calculator is a week. Keeping thirty of them right is the job — contribution limits and brackets move every January, and a wrong projection is the kind of bug users find before your tests do. Build when the math is your differentiator or your models are unusual enough that nobody sells them. License when you want the arithmetic to be someone else's maintenance contract and your team's time to go into the product around it.
- What does it actually cost to maintain tax constants in-house?
- The recurring cost is not the arithmetic; it is the annual work of finding what changed in the IRS and SSA figures, updating them, and re-checking everything that depended on them. Budget it as a fixed yearly obligation rather than a task, because it arrives every January whether or not anyone owns it. The model on this page uses 24 hours a year as a starting figure — replace it with your own.
- Is a cost model published by a vendor trustworthy?
- Not on its own, and you should not treat it as such. Every input here is labeled with the reasoning behind it so you can replace it, and the arguments against buying are stated on the page. What the model is good for is the shape of the cost — which parts are one-time, which recur, and which are the ones teams forget. If you disagree with every figure and still see the shape, the page has done its job.
- We already built our calculators. Is there anything here for us?
- The eval datasets, which are a different purchase from the API. Each is a set of deterministic input and expected-output pairs at the same tolerances our own verification harness holds, so you can run your engine against them in CI and find out whether it drifted. Teams use this to catch a January constants change before their users do.
- What is the risk of depending on a small vendor?
- Real, and worth pricing. We are a young company with no published customer list. What reduces the risk concretely: every model has a published specification, so the behavior you depend on is written down rather than living only in our code; the test cases are downloadable; and a spec version can be pinned. If we disappeared, you would have the specification and the cases needed to reimplement — which is more than most dependencies leave you.