Designing 25 screens for a money app
Most spending trackers are designed from the outside in. Someone draws a dashboard, then a transaction list, then works out what the data model has to be to support the pictures. It shows: the screens look fine and the app cannot represent a credit card properly.
This kit went the other way. It was drawn against a Product Requirements Document and an Architecture Document, both of which came from picking apart a real six-year tracking spreadsheet with around nine thousand transactions in it. That is why several of these screens exist at all, and why a few of them look unusual.
The first three screens are a promise
Welcome, theme picker, sign in. The order matters more than it looks.
The theme choice comes second — before the account, before any data. It is the app saying that this is yours to arrange, and it is also a quiet honesty signal: an app that asks you to pick a look before it asks for your email is not optimising for signups.
The welcome screen leads with a balance card, not a feature list. A spending tracker has about four seconds to communicate that it will show you a number you care about, and a screenshot of the thing itself does that better than three bullet points about privacy.
Sign in comes third, with four providers above the email field. Not because social login is fashionable, but because the free tier does not require an account at all — the whole sign-in screen exists to serve sync, which is a paid feature. An app that demanded an account before letting you log an expense would be contradicting its own pitch.
Onboarding ends at your spreadsheet
Step three of setup is Excel import, and it is the screen the whole product hangs off.
The insight from the source workbook was blunt: six years of history lives in spreadsheets, and nobody abandons that to start again at zero. So import is not a settings-menu afterthought — it is the third thing that happens, before the app has shown you anything of its own.
The screen does three things that most importers do not. It shows the detected sheet mapping, so a wrong guess is visible and correctable before anything is written. It reports a count of rows ready and a count flagged, rather than a progress bar and a cheerful result. And it offers to review the flagged rows rather than deciding for you.
An import that quietly drops what it cannot read is worse than one that refuses, because the loss is invisible until the month it matters. That is a screen decision and a schema decision at the same time — which is why the round-trip test, import then export then compare, is the one the specs treat as non-negotiable.
The ledger is sliced into books
Power users of spreadsheets do not keep one sheet. They keep a sheet per category — Food, Transport, Personal, one per person — and a master sheet that rolls them up monthly.
So the kit has Books: one ledger underneath, sliced into named views that behave like those sheets. Book detail is a transaction list scoped to one book with its own running total. Transactions is the same surface unscoped, with filters across the top. They deliberately share a layout, because in the spreadsheet they were the same thing seen twice.
This is the decision most likely to be undone during implementation. A developer who has not read the PRD sees two similar screens and builds two list widgets, and by the third one they have diverged. The kit's answer is that there is one list surface and everything else is a filter — which is both a design instruction and, in the prompt library, an explicit build order: extract the list once, before writing the second screen that needs it.
Cards carry dues, not balances
This is the screen that gives away where the design came from.
Most trackers model a credit card as an account with a negative balance. The source workbook tracked amount, paid and due per item, because that is what someone paying a card in instalments actually needs to see. So the Accounts screen splits into cash, bank, cards, assets and lending, and the card detail screen shows outstanding versus paid rather than one number.
Modelling this correctly is a schema decision, not a UI one — which is exactly why it is in the Architecture Document as well as on a screen. Retrofitting per-item dues onto a table that stores one balance per account is not a UI change; it is a migration, a rewrite of every query that touches accounts, and a week nobody planned for.
Growth is the number nobody shows
Reports gets the usual donut and the income-versus-expense bars. The screen next to it is the one that matters.
The source spreadsheet computed, per month: start balance, end balance, total debit, total credit, and growth. That last figure was the actual point of six years of tracking, and almost no consumer spending tracker displays it. The Growth screen reproduces the calculation exactly, month by month, with the same four inputs.
If you build only one screen from this kit, build that one. It is also the easiest to get subtly wrong — start balance and end balance have to reconcile across month boundaries, and a transaction dated on the first of the month has to land on exactly one side of that line. Which is why the prompt library asks for the tests, from worked examples you check by hand, before the query.
Add transaction is the screen that decides everything
It is a sheet, not a page: amount first, in a keypad large enough to hit without looking, then category, account and member as chips rather than dropdowns, then an optional note.
The stated target in the PRD is a first expense logged in under twenty seconds. That single number is responsible for most of the layout. Chips instead of pickers, because a picker is two taps and a wait. Amount before category, because the number is what you remember walking out of the shop. A cash-or-card toggle sitting inline, because it is the field people forget and then correct later.
It is also the screen that touches everything else — the schema, the theme, the navigation stack and the keyboard — which is why the prompt library builds it first, ahead of the dashboard and ahead of any list. If the foundations are wrong, this screen says so on day one rather than day thirty.
Money is a household, not a person
Spending in the source data was tagged to individuals — a child, a spouse — and to shared pools. Not as a premium feature, as the normal case.
So members are a first-class dimension: every transaction can carry one, budgets can be scoped by one, and the Household screen manages invitations and roles. Recurring sits beside it, because rent, internet, utilities and domestic help were the entries that repeated every single month in the workbook and dominated the total.
The receipt flow, including the part that fails
Four screens: enter a receipt, add line items, split them across books and members, and cross-check the total against the printed one.
The fourth screen is the mismatch state. The line items add up to something the receipt does not, and the screen says so, shows the difference, and offers to add a balancing item or save anyway.
Most kits stop at the happy path. But anyone who has typed a shopping receipt into an app knows the totals disagree perhaps a third of the time, and what the app does in that moment decides whether the habit survives. A design that has no drawing for its most common failure has not really been designed.
The paywall says what it takes
Two screens carry the commercial model, and both are more candid than they need to be.
The upgrade screen lists four things — auto-sync and cloud backup, multi-device, multi-currency, shared household — and nothing else. No feature grid with grey ticks, no artificial limit on the free tier. The free tier in this product is genuinely complete and genuinely private: it never touches the server at all. What you pay for is the network, which is also the only part that costs anything to run.
The sync status screen is the other half of that promise. It shows what has actually synced and what has not, rather than a spinner and a hopeful checkmark. An offline-first app that cannot tell you what is still local has not finished being offline-first.
Three themes, no repainting
Pocket is bright and friendly, Ledger is warm and editorial, Vault is dark and minimal. The same dashboard in all three, and the same add-transaction sheet.
The point is not that there are three. It is that every screen is drawn from theme tokens rather than literal colours, so the third one cost almost nothing and a fourth costs one file. That is the difference between a design system and a set of pictures that happen to match, and it is the property most likely to be lost in the first week of implementation.
Where to go from here
All twenty-five screens are in the kit, in the three themes, as a single HTML canvas you open in a browser. The PRD and Architecture Document ship with it, so the reasoning above is available in full rather than summarised. There is also a 43-prompt library for building it in Flutter with Claude Code, in the order that surfaces the hard problems on day one instead of day thirty.