How I built a source-backed UK and Netherlands financial calculator platform
I started building Qalqlet after noticing the same problem across many financial calculators: they provide a number, but often give very little context about where it came from.
A take-home salary figure can look precise while hiding important details:
Which tax year was used?
Does the calculation include pension contributions?
Which region or tax rules apply?
When were the underlying thresholds last reviewed?
What does the result exclude?
I wanted to build something more useful than another isolated salary calculator.
The real question is rarely just “What is my net salary?”
People usually arrive with a simple question, but the decision behind it is much larger.
Someone comparing job offers may also need to ask:
How much will I actually take home?
How will pension contributions affect the result?
What size mortgage could I potentially afford?
How much might housing and household costs leave each month?
Would the same salary support a different lifestyle in another country?
That led me to build Qalqlet as a connected financial decision platform rather than a collection of unrelated calculators.
The UK platform currently covers salary, tax, mortgage, pension, benefits, business and household tools:
https://qalqlet.com/uk
Connecting financial decisions
A typical calculator website gives the result and ends the journey.
Qalqlet tries to connect the next relevant question.
For example:
Salary → tax → pension
Mortgage → affordability → household budget
Business income → tax → personal take-home
The goal is not to force users through a funnel. It is to help them understand which calculation naturally comes next.
The platform is free to use and does not require an account.
Why I added the Netherlands
I wanted to test whether the same product structure could support another country without mixing its rules with the UK system.
The Netherlands was a useful second market because it has strong demand around salaries, mortgages, benefits, pensions and expat decisions, but its financial and tax systems are materially different from those of the UK.
Instead of translating UK calculators and changing the currency symbol, I created a separate Netherlands route:
https://qalqlet.com/nl
The Dutch section is Dutch-first, with English available as a secondary route where it helps international users.
Keeping country rules isolated
One of the most important architectural decisions was to keep UK and Netherlands calculation rules separate.
This reduces the risk of:
Applying one country’s thresholds to another
Mixing tax years
Publishing translated calculators with incorrect logic
Updating a shared rule and unintentionally breaking another market
Shared design and publishing components can still be reused, but the underlying country rules, sources and review processes remain isolated.
This creates more work initially, but it should make future country expansion safer.
Official sources are only part of the solution
Saying that a calculator uses official sources is not enough.
Financial rules change. A source may be correct but outdated, incomplete or interpreted incorrectly.
I therefore added a methodology and update policy that aims to show:
Where the rules came from
Which period or tax year applies
When important data was reviewed
Which assumptions are used
What the result includes and excludes
The methodology is available here:
https://qalqlet.com/uk/sources-and-methodology
The calculations are intended for planning and decision support, not as replacements for professional tax, payroll, mortgage or financial advice.
Building the UK and Netherlands comparison
Once both country routes existed, the next question was obvious:
How can someone compare an opportunity in the UK with one in the Netherlands?
A gross salary comparison is rarely meaningful on its own. Taxes, housing, healthcare, childcare and local costs can materially change the outcome.
I built a London versus Amsterdam comparison page that combines salary and local-cost scenarios:
https://qalqlet.com/uk-vs-nl
It is still a planning model rather than a definitive answer, but it is closer to the question users actually want to answer:
“Which place could leave me with more money after the important local costs?”
What I learned
A few lessons from building Qalqlet:
- The calculation is not the whole product
Explaining assumptions, limitations and next steps is just as important as displaying the result. - More calculators do not automatically create more value
The tools become more useful when they support a connected decision journey. - Country expansion is an operational challenge
Translation is the easy part. Maintaining sources, rules, review dates and local intent is the difficult part. - False precision damages trust
A financial estimate should be labelled as an estimate when it cannot represent every individual circumstance. - Distribution needs to be designed into the product
Each calculator should answer a specific high-intent question, but it should also help the user continue to the next relevant decision.
What comes next
My current priorities are:
Improving the most-used UK and Netherlands calculators
Making assumptions and source information easier to understand
Expanding the cross-border comparison experience
Learning which calculator journeys users actually complete
Validating sustainable monetisation without compromising trust
Deciding which country should be supported next
Qalqlet is currently bootstrapped.
I would genuinely appreciate feedback from other founders:
Does the source and methodology approach increase your trust?
Which calculator would you use first?
Is the UK–Netherlands comparison useful?
Which country should Qalqlet support next?
UK platform: https://qalqlet.com/uk
Netherlands platform: https://qalqlet.com/nl
UK–NL comparison: https://qalqlet.com/uk-vs-nl
On freshness and uncertainty, from the same shape of problem on the e-invoicing side, where the rules arrive as published authority rulesets that are versioned and do move:
The thing that helped most was treating the pin as a pair rather than a version. A number is not produced by "tax year 2026/27", it is produced by that rule set as published in one specific artifact revision. "Reviewed 12 July" tells a user that someone looked, which is a promise about your process. "Computed with , , revision X" tells them what actually ran, which they can go and check. The second is falsifiable and costs the same amount of UI.
On your regression cases: the version that earns its keep is a fixture whose result is expected to differ between two rule versions, with CI failing when it stops differing. We keep the previous ruleset vendored next to the shipped one for exactly that, with the flip recorded per rule. It turns a source update from a behaviour change you discover into a decision you make, and it also catches the nastier direction: a source changes, nothing in your output moves, and the reason is that the rule you transcribed was never actually wired in.
On not overwhelming people, I would avoid expressing any of it as confidence. Your calculation is deterministic, so the uncertainty is not statistical, it is which assumptions applied and which were excluded. One default line naming the single exclusion most likely to move that user's number ("assumes no student loan plan and no salary sacrifice") does more than a percentage or a badge, and the full methodology stays one click behind it for the people who want it.
This is an excellent distinction. “Reviewed on” describes our process, but an artifact revision identifies what actually produced the result. The latter is much more useful because it is specific and falsifiable.
The differential fixture point is especially valuable too. We shouldn’t only test that old cases still pass; we should have cases where a rule change is expected to produce a different result, and fail CI if that change has no effect.
And I agree on avoiding confidence scores. The uncertainty here is not statistical — it comes from assumptions and exclusions. A plain line such as “Assumes no student loan plan or salary sacrifice” is probably more useful than a confidence badge.
This gives us a much clearer direction for the provenance and regression work.
Freshness feels like the load-bearing feature here. I’d show an “inputs last verified” date beside every result and keep historical tax-year test cases. Are you already automating any of that?
Partially. We already track source metadata, review dates, and country-specific rules, and we’re building regression cases for previous tax years so updates don’t silently change historical results.
The update pipeline can flag source or rule changes, but we keep a human review step before publishing anything. We haven’t surfaced the “inputs last verified” date prominently beside every result yet — that’s a very good UI improvement, and probably the next freshness feature we should ship.
The transparency problem in financial calculators is bigger than most people realise. I've used tools that gave me a salary figure with no mention of which tax year, whether it accounts for the personal allowance tapering above £100k, or whether the pension contribution is pre- or post-tax. You end up trusting a number you can't interrogate.
The approach you're describing, showing the reasoning not just the result, is actually what makes a tool trustworthy rather than just functional. UK-specific too, which matters because a lot of the generic tools treat it as an afterthought.
Is the source-backing auditable by the user? Curious whether you're surfacing the HMRC references or keeping it under the hood.
Yes — the source-backing is user-visible, not just something we keep under the hood. Each calculator is intended to show the relevant source, tax year or period, review date, assumptions, and exclusions.
We’ve also published the broader methodology and official-data policy here: https://github.com/icostand/qalqlet-methodology
The goal is that users can question the number instead of just trusting it because it looks precise.
Building the methodology alongside the calculators is a thoughtful choice.
Especially in financial tools, showing where a number came from changes the experience quite a bit compared with simply presenting the result.
Thank you — that was exactly the motivation. A financial calculator can produce a correct-looking number and still create a misleading experience if the user doesn’t know what’s behind it.
Making the methodology visible adds a little complexity, but I think that trade-off is worth it when the result could influence a salary, mortgage, or relocation decision.
A small follow-up for anyone interested in the technical and editorial side:
I’ve published Qalqlet’s methodology and official-data policy publicly here:
https://github.com/icostand/qalqlet-methodology
One of the hardest parts has not been building the calculation forms. It has been deciding how to track source changes, applicable tax years, review dates and country-specific assumptions without creating false confidence.
I’d especially value feedback from other founders working with financial, legal or other rules-based data:
How do you communicate data freshness and uncertainty without overwhelming users?