AI LABWorking prototypes, and the decisions inside them
Self-directed product work built with Claude, most of it fintech. Six visual directions across four products, on iOS and on the web, several of them the same problem approached more than once on purpose. Links to live prototypes are included for each example.
Concepts and explorations. Synthetic data throughout, no live financial connections.
Six visual directions across the four projects below. Margin, Tax reserve, Spaces, Treats & Trinkets, FirstLight, Dream Thread.
How these were made
What the model is good for
Getting to a working, clickable thing fast enough that a bad idea can be killed in an afternoon instead of defended for a week. That changes what is worth trying at all, which is most of the value.
What it is not good for
Deciding. Unconstrained it returns the same competent default every time: dark ground, teal accent, one large number, a stack of cards. The first entry below exists because I wanted to watch that happen, and then find out what it takes to stop it.
Where the work actually is
Writing constraints that force a different structure rather than a different palette, then reading the output closely enough to catch where it hedges, flatters, or states a guess as a fact. Most of my edits are to copy and to the order information arrives in, not to layout.
What I check every time
That the arithmetic agrees across screens, that nothing claims more certainty than the data supports, and that no evaluative language has got into a number.
FINTECH · MOBILE · METHODThree answers to the same money problem
Freelance income arrives unevenly, so a bank balance is a poor guide to what is actually safe to spend. That brief was built three times over. Margin forecasts, Tax reserve sets money aside first, Spaces puts it into named piles. Same user, same maths, same screens, three different arguments about what the person should be looking at.
Freelance cash flow · iOS · Margin, Tax reserve, Spaces · Built with ClaudeAll three, same brief
Margin. Dark, forecast-led. The number, the forecast it rests on with its likely range, and the one buffer you set yourself
Tax reserve. Daylight, obligation-led. Money goes away before it can be spent, with the quarterly deadline on the home screen
Spaces. Warm, container-led. No forecast at all, just named piles you can see the edges of
The design problem
Ask a model for a personal finance app and it will produce the same one every time: dark ground, teal accent, one large number, a stack of cards. The defaults are competent, which is exactly what makes them hard to notice.
Holding the brief constant and forcing genuinely different answers separates the decisions from the defaults. Margin is the default, kept deliberately as a control. Tax reserve and Spaces exist to argue with it.
Margin is still the one I would ship. The point of building Tax reserve and Spaces was being able to say why.
What I decided, what the model produced
Left to itself the model returned Margin three times with the hue changed. The useful work was writing constraints that forced a different structure rather than a different palette: no forecast in Spaces, no dark ground in Tax reserve, a different primary action in each. Read a number, move money, assign money.
Interactive concepts. Synthetic figures, no bank connection.FINTECH · MOBILE FIRST · CONCEPTMaking small spending visible without making it shameful
Discretionary spending stays invisible because every individual purchase is defensible. This totals the small things across months, shows the shape they make, and hands the judgement back to the person instead of passing it. Designed for the phone first, then opened out to the web. Both versions carry the same features and the same sentences, so the only thing that differs between them is structure.
Treats & Trinkets · Mobile first, then web · Five screens · Built with ClaudeThe app opens on what happened while you were away. Defer it and the job stays in the tray
June at full size, the months before it as context, and a calendar built around the week
The split as numbered steps, with the disclosure sitting at the projection
The same trail on the web. Five months at equal weight with an average line through them, and the calendar sitting beside the context chips rather than above them
The same trail on the web. Five months at equal weight with an average line through them, and the calendar sitting beside the context chips rather than above them
The design problem
Every product in this category defaults to reprimand. The tone had to stay warm while the arithmetic stayed exact, which meant splitting the two jobs: the interface carries the numbers, the person carries the verdict.
That is why there is a rules screen. What counts as a treat is a setting, not an assumption the product makes on someone's behalf.
Same palette, same type, same features, same sentences. What changes is how much can be shown at once, and every difference above follows from that. Responsive would have changed the widths and left the structure alone.
Same features, decided twice
Five months, or one
The web shows all five months at equal weight with an average line running through them, because five bars fit in a single glance. Mobile gives June the full-width bar and its own number, and drops the rest into a band labelled before that. The web answers how these compare. The phone answers how this month went.
The label folds into the control The web sets February to June 2026 beside a three months and five months toggle. The phone folds the dates into the buttons themselves, so the control states its own range. One line saved, on a surface with no lines to spare.
What I decided, what the model produced
The first pass at the copy graded the spending. Every evaluative word came out of the totals, and the judgement moved into a threshold the person sets.
The first pass at mobile was the web layout at a narrower width. Rebuilding it phone-first changed the structure, and the web version was then rebuilt from what the phone had taught it, which is why both now carry the same queue, the same written verdict on the chart, and the same context chips.
Interactive concepts. Synthetic transactions, no bank connection. Illustrative returns only, nothing here moves money.A month, or a week at a time The charm trail carries the same encoding on both: one mark per purchase, size for amount, shape for category. The web runs the whole month on one axis and has room to mark the day the €250 line was crossed. The phone pages it into weeks you swipe, because thirty marks across a phone is a smudge.
Beside, or after
On the web the calendar and the context chips sit in two columns, so you can see a heavy day and label it in one movement. On the phone they stack: the calendar makes its point, then the labelling follows. One is simultaneous. The other is a sequence, and reading order becomes the only hierarchy available.
Words the column already says The web legend reads one treat, two treats, three or more, and each week totals four treats. The phone reads one, two, three or more, and four. The scale is identical and nothing is abbreviated that could be misread. The only words removed are the ones the column heading has already supplied.
The margin holds what persists
The web keeps the account and the last-updated time in the header all the way down, and offers view as a table beside the chart. The phone has no margin, so the one figure that has to persist collapses into the header as you scroll past it, and the table is not offered at all, because a table at that width is not a table.
RESPONSIVE WEB · COMMERCE · CONCEPTCarrying someone from a landing page to a paid report
The only prototype here with a commercial spine running end to end. Someone arrives, is persuaded, pays, receives something, and can come back to it later. Twelve screens covering the parts of a product that usually get skipped in a portfolio: payment, account, empty states, export.
FirstLight · Responsive web · Desktop and mobile · Twelve screens · Built with ClaudeA specific claim rather than a category description, priced in view
A single charge, with what arrives afterwards stated before the payment rather than after it
The product itself, structured so it can be read in two minutes or forty
The reason to come back
The same flow on a phone. The report holds as one column, which is the test that mattered
The design problem
A one-off purchase has no second chance. There is no subscription to smooth over a bad first impression and no onboarding drip to explain what was bought, so the report has to deliver on the landing page's promise immediately and completely.
That put the weight on the least glamorous screens. What the intake asks for, how the wait is handled, what the library looks like holding one item, whether the export is worth keeping, and whether a report built to be read at desk width still holds as one column on a phone, which is where most people would open it.
What I decided, what the model produced
The first treatment ran light and high-contrast with a hot accent, which read as consumer marketing rather than something a person pays for once. Rebuilt dark, with the accent pulled back until the report itself is the brightest thing on screen.
Interactive concept. No live payments.