Permute

UK household financial planning

By Vignesh Prasad, Principal Product Designer at Ebury

permute.co.uk is household financial planning software for the UK. You enter your own numbers and it projects them forward under assumptions you control.

It is a planning tool and not regulated advice: every figure is an estimate, every result a scenario. Invite-only beta for now.

It is a personal project. I built it on my own, with Claude, to make a financial plan for our household. I made the decisions.

Nothing landed in the repo that I had not read, and a fair amount of it I changed.

Reviewing generated code is its own skill. The mistakes are rarely obvious. The code is usually well-structured and plausible, with a single wrong assumption somewhere inside it.

The structure around the code mattered more than the code generation itself.

Specs before code

The first commit is a product plan. The first line of application code arrives four days later.

That order stuck. Specs are ground truth, so a session reads the relevant one before changing behaviour and updates it in the same branch as the code.

Alongside them sits PROVENANCE.md, a dated log of every decision: scope, naming, pricing, architecture, legal stance, which personas I hired and when. Append-only, so nothing gets tidied up later.

I started it as a memory aid. It also records who made each decision, which matters for a product built this way.

Every session also has to consult Graphify before it touches code. It is an open-source knowledge graph that maps the repo into typed entities and relationships, so the assistant follows real paths instead of grepping around.

Query the graph, make the change, update the graph. In this repo that is not optional.

The gate at the bottom of that loop makes the rest possible. Typecheck, lint and tests green before anything is pushed, and CI runs the same check on every PR.

Merging to main is a production release, so a bad merge reaches users immediately.

An engine that refuses to give advice

The engine is pure. No clock, no randomness, no network.

Feed it the same numbers twice and you get identical output, which is the only reason the financial maths is testable at all.

Money is integer pence everywhere. Pounds exist at exactly one place, the moment something renders.

What it models:

  • UK income tax and National Insurance per earner, including the Personal Allowance taper between £100k and £125k
  • Pension access age at 55 today, 57 from 2028
  • Banded stamp duty, goals, and affordability against projected net worth
  • Monte Carlo on seeded, reproducible trials

There is one thing the engine will not do.

It emits numbers and structured drivers, never recommendations, and the UI turns those drivers into sentences. The compliance boundary sits in the architecture rather than the copy, so it holds even when I am moving quickly.

It is also incomplete. Pension withdrawals are modelled gross, and dividend and savings allowances are out of scope for now.

The education layer has to teach around those gaps without contradicting them.

A company's worth of roles, solo

The repo carries seven AI personas: cofounder, content designer, principal engineer, design engineer, platform engineer, user researcher, general counsel.

Each one is a SKILL.md file containing this product's decisions and constraints.

Claude invokes them as skills, and any other tool reads the same markdown as plain instructions, so the roles are portable.

I add them deliberately, with a trigger for each. Marketing lead is parked until public launch.

The review loop runs both directions.

An AI review caught a silent data-loss bug in code I had written and shipped the fix with regression tests.

The Monte Carlo work went the other way: largely AI-implemented, reviewed by me line by line. Pension access age modelling only exists because that review found it missing.

Honesty as a constraint

A few decisions cost something each time:

  • Backtesting shipped first on a provisional dataset, flagged as provisional, then replaced with a verified series from JST Macrohistory and the Bank of England before any tester saw a backtest
  • End-to-end encryption is opt-in and off by default. Mandatory zero-knowledge looks better on a landing page, but it locks out any household that loses a passphrase and a recovery key
  • No analytics and no trackers, which is a published promise rather than a setting. The consequence is that user research has to be qualitative
  • "FIRE" was retired in favour of "financial independence", with a CI test that fails the build if it reappears in source

Seeing the graph

I wanted to see the graph rather than only query it, so I built a 3D visualisation of Graphify's output where every node is a shader-driven bubble.

It is at code-bubbles.labs.srivi.me if you want to spin one around.