Money math in plain JavaScript: lessons from building a loan calculator

Sampo Mannila — Thu, 12 Nov 2026 13:06:13 +0000

Laskuri.org is a Finnish site with more than two dozen calculators: loans, compound interest, percentages, unit converters, fitness formulas. It is a static site with no framework and no bundler. Each calculator is one plain JavaScript file.

The loan calculator was the hardest one to get right. These are the things that mattered.

Parse numbers the way people type them

Finnish users write 10 000,25, often with a non-breaking space, and negative rates sometimes arrive with a real minus sign (U+2212) pasted from a bank's page. Number() rejects all of these. The parser accepts them and refuses anything ambiguous:

function parseNumber(value) {
  const s = String(value).trim()
    .replace(/\u2212/g, '-')
    .replace(/[ \u00a0\u202f]/g, '');
  return /^[+-]?(?:\d+(?:[.,]\d*)?|[.,]\d+)$/.test(s)
    ? Number(s.replace(',', '.'))
    : NaN;
}

1,000.00 and 1e4 return NaN on purpose. Guessing which separator the user meant is worse than asking again.

Count in cents

Every balance and payment is an integer number of cents. Interest is rounded once per month, the way a bank statement shows it, and the last payment is whatever clears the balance to exactly zero. With floating-point euros the schedule drifts by a cent somewhere around year fifteen, and users notice.

Equal-principal loans have their own trap: dividing the amount by the number of months and rounding each instalment does not add up. The calculator rounds the cumulative principal instead and takes the difference, so the instalments always sum to the loan.

Use expm1 and log1p for the annuity

The textbook annuity formula subtracts two numbers that are almost equal when the monthly rate is small. Math.expm1 and Math.log1p exist for exactly this:

function annuity(principal, annualRate, months) {
  const r = annualRate / 1200;
  return r === 0
    ? principal / months
    : principal * r / -Math.expm1(-months * Math.log1p(r));
}

The zero-rate branch is not optional. Reference rates were negative for years, and a zero total rate is a real input.

The effective rate has no formula

The annual percentage rate, with fees included, is the rate at which the discounted payments equal the money the borrower actually received. There is no closed form, so the calculator brackets the answer by doubling and then bisects a hundred times. It is slower than Newton's method and never diverges, which matters more in a browser.

One file for the browser and for the tests

Each calculator file ends its pure part with two lines:

if (typeof module !== 'undefined' && module.exports) module.exports = api;
if (typeof document === 'undefined') return;

In the browser the file carries on and wires up the form. In Node it stops after exporting the functions, so the tests need no bundler and no DOM:

test('known annuity benchmark: 100000, 5%, 30 years', () => {
  close(annuity(100000, 5, 360), 536.8216230121398);
});

The site has over two hundred of these tests, run with Node's built-in test runner and no dependencies.

Live rates without a fragile page

The calculator pre-fills the Euribor reference rate from the Bank of Finland. That is the only server-side code on the site: one small PHP endpoint that fetches the published rates, caches them for six hours, and refuses to replace a cached quote with an older one.

The page does not depend on it. A snapshot of the rates is embedded in the HTML at build time, the request to the endpoint has a timeout, and if both fail the user gets an example rate and a note asking them to type their own. The rate field stays editable in every case.

What I would do again

Keep the math in pure functions with no DOM access.
Store money as integers.
Test against a published benchmark, not against your own output.
Treat every live data source as something that will be down one day.

The most important file in our repository is the one written for AI agents

Sampo Mannila — Wed, 11 Nov 2026 12:37:35 +0000

We run a network of Finnish-language guide sites from a single GitHub repository. Most of the day-to-day work is done by AI coding agents: content updates, new pages, fixes and deployments. I have written about the setup elsewhere. This post is about one file in it, the instruction file at the root of the repository, and what ended up in it after two months of real use.

Why a file and not a prompt

An agent starts every task from zero. It does not remember yesterday's mistake or last week's decision. Anything that should carry over has to be in the repository, where the next session will read it.

We also use two different agents on the same repository. A shared file is the only place where both get the same rules.

So the file is short, checked in, and reviewed like code. Almost every line in it is there because something went wrong once.

The rules, and where they came from

Read the status page first, not the history. Early on, agents would read weeks of old task notes before touching anything. Now there is one short status page and a handoff note per site. The history exists, but nobody reads it for a routine change.

An instruction to act covers the whole route to live. If I ask for an update, the agent builds, checks, merges and deploys without asking again at each step. If I say "show me first", it stops there. Asking for the same permission twice is listed as an error.

Make the smallest change in the permanent source. No rebuilding a site from scratch, no new import, no redesign on the side. This rule exists because agents are very willing to improve things nobody asked about.

Check what changed, not everything. A one-line text edit used to trigger browser tests on every page and a fresh backup. The file now says that verification follows the size of the change, and that a result already produced for the same version is not repeated by hand.

Dates are facts. A page keeps its verified first publication date. Only a page whose content really changed gets a new updated date. Build times and site-wide stamps are forbidden, because they make old content look new.

Partner placements are an agreement, not a layout. The order of partners on a page and the offers shown come from a monthly register. A redesign may not move them, and last month's agreements are not carried over by default.

Do not rerun a failing job blindly. When a deployment fails, the agent has to find the actual cause first. There is exactly one documented exception, for a known transient error from the hosting provider's API.

One record per change. The deployment run and its summary are the record. No separate documentation pull request, no status line for a routine edit, no copying the same report into three files.

Leave the other agent's work alone. Whoever gets the task finishes it. Unfinished branches belonging to the other agent are not touched.

A rule that was missing

Rules also have to be removed. We had a check that pinned certain files by checksum so that imports could be verified. One of the pinned files was the status page, which changes all the time. The pin went stale and started failing unrelated pull requests. The fix was not a better pin but taking the living document out of the list.

The lesson I took from it: a guardrail on a file that is supposed to change is a bug, and the agents will dutifully work around it until someone deletes it.

What I would copy

Keep the file short enough that it is read in full every time.
Write the reason next to the rule when the reason is not obvious.
When an agent does something wrong twice, change the file, not the prompt.
Review instruction changes in pull requests like any other code.

The agents are capable. What they lack is the context of last week, and this file is where that context lives.

DEV Community: Sampo Mannila