01Introduction
True Available Cash
The balance says you have it. It does not say you can spend it.
A concept for the finance lead who has to answer the one question a bank account cannot: how much can we safely spend today — and is this particular decision one of the safe ones.
A self-initiated fintech concept that turns a bank balance into an answer: £84,500 visible, £29,600 actually spendable, and a verdict on whether a proposed decision is safe — with the reasoning attached to it.
Every figure on these screens is illustrative. Nothing here is measured; what would prove it is listed at the end.
- Problem framing and the product thesis
- Product strategy
- UX and UI design — the decision layer end to end
- The verdict model: states, thresholds and reasoning
02The gap
Eighty-four thousand in the account.Twenty-nine of it is yours.
A business banking screen shows one figure and presents it as money. Most of it is already spoken for — owed on a date that has not arrived, reserved against a tax bill, or sitting inside an invoice that may never be paid. The balance is accurate, and it is not the answer to any question anyone is actually asking.
- Reserved£21,000Tax and buffersAlready belongs to someone else, on a date that has not arrived yet.
- Committed£24,700Payroll and suppliersOwed, scheduled, and not movable without breaking something.
- At risk£9,200Overdue and disputedAn invoice twelve days late and formally disputed. It may not arrive at all.
- Available£29,600What survives all threeThe only figure in this list that can be spent.
The gap is £54,900 — sixty-five per cent of the balance. That is not a rounding error, it is most of the money. And it is arithmetic a finance lead is expected to carry in their head, correctly, every time somebody asks whether the company can afford something.
Can we spend £12,000 on equipment today?
Knowing that £29,600 is available does not settle it. £12,000 is comfortably less than £29,600 — and the answer is still not a straightforward yes. Everything after this chapter is about why.
03The bet
A better numberwas not the answer.
There is an obvious version of this product that stops at the previous chapter: surface Truly Available instead of Total Cash, colour the buckets, ship it. It would be a more honest dashboard, reporting a more accurate figure — to somebody who then has to do all of the actual thinking on their own.
But a finance lead is not employed to know the balance. They are employed to decide. Every accurate figure on that screen is an input to a question the screen refuses to answer, and the distance between seeing financial data and acting on it is precisely where the mistake gets made.
So the unit of this product is not the balance. It is the decision — proposed, evaluated, explained, and kept. Everything after this chapter is what that move cost.
04The verdict
Twelve thousand, judged againsta position, not a balance.
£12,000 is less than £29,600, so a balance check returns yes and stops there. The concept does not check the balance. It checks what the decision leaves behind, and whether what is left can absorb the things already known to be uncertain.
One month of fixed running costs, set in the company’s own rules rather than by us. A floor is a policy, and a product that picks one on your behalf is making a decision it has no standing to make.
- £17,600Left after this decision£29,600 truly available, less the £12,000 proposed.
- £2,600Room above the floorIt clears — by roughly five days of running costs.
Safe today, and not safe if one more thing moves.
The £9,200 disputed receivable is already excluded from Truly Available, so the £17,600 does not depend on it arriving. What it does depend on is nothing else changing: £2,600 of room is one unexpected cost away from the floor. That is why the verdict is not a plain yes, and why the interface names the condition instead of leaving the reader to infer it. A bare no gets overridden by whoever wanted the equipment. A reason gets planned around.
05Three decisions
Three decisions, andwhat each one cost.
The bet was written before any screen: the unit of this product is the decision, not the balance. Every screen was judged against it.
- 01
Truly Available is the headline, not Total Cash
The largest figure on the overview is £29,600. The bank’s own number is still present, but demoted to one of four inputs sitting beside it.
The trade-offIt contradicts the figure in the user’s banking app, on the first screen, before any trust has been earned. We accepted that the product has to explain itself immediately or be dismissed — which is why the breakdown sits directly beneath the number rather than one click away.
- 02
Every verdict carries its reasoning
The system never returns a bare Safe or Unsafe. Each verdict names the figures it was reached from — available cash, the floor, the commitments, the exposure — in the same view as the answer, not behind a details link.
The trade-offA reason is slower to read and much harder to build. A yes or no is one comparison; an explanation has to be assembled from every input and stay correct as any of them change. We took the cost because an unexplained no gets overridden, and a product that is routinely overridden is not being used.
The verdict, with the figures it was reached from - 03
Uncertainty is counted, not hidden
Stale feeds and unresolved disputes appear as At Risk alongside genuine receivables. A gap in the product’s own information is treated as a threat to the position rather than as a blank space.
The trade-offIt means telling the user that the product does not fully know the answer, which is the opposite of what a confident interface does. The alternative is worse: quietly treating unknown money as available is how a safe verdict turns into a missed payroll.
Exposure, disputes and the product’s own data gaps, in one list
06Constraints
What the productis not allowed to do.
Each of these removed an option a cleaner design would have taken.
- Read-only
The concept never moves money. It reads positions and returns verdicts; the payment still happens somewhere else. Advising and executing inside one tool needs a different class of permission and a different conversation about liability.
- Imperfect inputs
Bank feeds lag, reconciliations run late, and a clearing balance can be hours stale. The design has to stay correct while its own data is not — which is why staleness is a visible category rather than an error state.
- The floor is the company’s
Thresholds are policy. The product asks for them, applies them consistently and shows its working. It does not decide what a safe buffer is on the user’s behalf.
- Not advice
Every verdict is a calculation against the company’s own stated rules, and is worded as one. Nothing in the interface phrases itself as a recommendation about what the business ought to do.
07What this rests on
Nobody was interviewed.So here is what it assumes.
This is a concept, not a client engagement. Rather than dress that up, here is exactly what would have to be true for it to work.
- A1
That a finance lead will trust a figure which contradicts their banking app. This is the hardest assumption here, and the one the entire product depends on.
- A2
That commitments, reserves and exposure can be classified reliably enough from accounting and banking data to be worth automating. Every misclassification moves the headline number.
- A3
That an explained verdict actually changes behaviour, rather than being read once and then ignored the way a warning banner is.
- A4
That a business has, or can be persuaded to state, an operating floor. Without one there is no threshold and no verdict — only a prettier breakdown.
A1 is the one most likely to kill it. It is listed first for that reason.
08What exists
Built as a concept,figures and all.
Nothing here is measured, and every amount on these screens is illustrative. This states what exists and what would be tested — not what was achieved.
- Problem framingConcept
- The user, and the decision they are actually making
- Five financial states, and why the balance is not one of them
- The design bet, written before any screen
- Four assumptions, including the one that would kill it
- Product designConcept
- Seven core flows, desktop at 1440
- Overview, cash breakdown and risk register
- Decision evaluation with an explained verdict
- Saved decision scenarios, linked to what they rest on
- What we would testHypothesis
- Whether a finance lead accepts a figure lower than their bank’s, against a control shown Total Cash
- Decisions reversed after reading the reasoning, against decisions made on the balance alone
- Whether saved scenarios are ever reopened, or written once and forgotten
The claim is that a decision made against £29,600 is a better decision than one made against £84,500. That is the hypothesis. It has not been tested.