Morris Solutions
Live2026

Retirement modelling for two tax jurisdictions, with the tax done properly

Advisers need to show a client what their retirement income actually looks like after tax — and most calculators get the tax wrong in ways nobody notices.

The problem

An adviser sitting with a client needs to answer one question: if you retire on this much, with this pot, how long does it last and what do you actually take home?

Answering it properly means modelling the tax year by year. Most tools either skip that, or apply a flat rate, or implement the brackets in a way that is subtly wrong at exactly the income levels their clients occupy — and a spreadsheet that is wrong by a few percent a year compounds into advice nobody should be acting on.

What it does

A set of client-facing tools, one per jurisdiction. Sliders and number inputs for the pot, the drawdown rate, growth, inflation, expenses and age. Three outputs update live with every keystroke: summary result cards, a balance curve, and a full year-by-year cash flow schedule.

No submit step, no server, no account. The whole tool is a single HTML file that can be emailed and opened.

How it’s built

Each tool runs a deterministic year-by-year simulation. One array — a row per year — is the authoritative output, and the cards, the chart and the schedule are all derived from it. Change the simulation and the display follows; there is deliberately no second source of truth.

The tax engines are the hard part, and they are separate per jurisdiction — same design system and input layer, entirely different rules, never cross-imported.

The decision that mattered

Both engines back-solve by binary search rather than algebra: given a target net income, find the gross withdrawal that produces it.

That looks like the lazy choice and isn’t. The tax function is piecewise linear with kinks at every bracket edge, and a closed-form solution needs case handling per segment — more code, and wrong in a way that only shows up near a boundary.

The detail most calculators miss sits in exactly that region. In the UK, the personal allowance tapers away above a threshold, and the basic-rate band is measured from the tapered allowance, not the full one. Get that wrong and the model is accurate everywhere except inside the taper window — a band of income wide enough to matter and narrow enough that casual testing sails straight past it.

Tax logic is extracted and unit-tested against known bracket boundaries before it goes anywhere near the interface. That has already caught one real marginal-rate error.

Outcome

Four tools across two jurisdictions, complete and in client use. Two independent tax engines, both unit-tested at their boundaries.

Built with
Single-file HTMLChart.jsNo build step

Want something like this for your business?

Tell me how this works for you today and where it gets stuck.