CONCEPT PROJECT · FINTECH · AI-ASSISTED EXPLORATIONFrom a freelancer pain point to a testable fintech concept in one day
I used AI to turn an early problem signal into a working product concept in one day — from product framing and financial logic to interaction design and a functional prototype.
The experiment was less about generating screens quickly and more about testing where AI could accelerate execution without replacing product judgment.
Conceptual prototype · Synthetic data · No live bank connection · Not financial advice
Project details
Margin — an experimental personal-finance concept for freelancers
Irregular income makes a bank balance a poor indicator of what is actually safe to spend.
Product framing, financial model, interaction design, prototyping, and feasibility exploration
One-day concept sprint
AI-assisted research synthesis, logic exploration, prototyping, critique, and code
Concept / proof of concept
A bank balance is not the same as money you can safely spend.
I treated AI as an execution partner rather than a product strategist. It helped me move quickly through research synthesis, alternative models, interface production, critique, and implementation, but I kept the core product decisions explicit.
AI accelerated production, not product thinking.
I gave myself one focused day to move from an early problem signal to an interactive mobile proof of concept.
AI accelerated interface production, variations, prototype code and rapid iteration. I remained responsible for the product framing, financial logic, interaction decisions, boundaries, visual direction and evaluation.
What AI accelerated
Interface production
Variations
Prototype code
Rapid iteration
What remained my responsibility
Product framing and financial logic
Trust and boundaries
Visual direction
Evaluation
I deliberately didn’t use AI for
Inventing research evidence
Making financial claims
Deciding what users should trust
Replacing validation
Explore the prototype
The prototype is intentionally narrow: enough of the experience is functional to test the core product logic and interaction model.
Suggested path: review £500 safe to spend → explore the £700 purchase → compare options → inspect the assumptions behind the result.
The model is conservative with uncertain money.
The product should never make uncertain money feel safely spendable simply because an algorithm can produce a number.
So I designed the model to treat ambiguity conservatively: committed obligations reduce available money first, while uncertain future income contributes less confidence to the recommendation.
When the data is uncertain, the product should become more cautious, not more persuasive.
The main flow tests a real decision rather than a generic dashboard.
I didn’t want the home screen to become another financial dashboard full of numbers users had to interpret themselves.
The primary job is to answer one decision:
Can I safely spend this amount right now?
Supporting information (runway, upcoming obligations, income variability, and account detail) exists to explain that answer rather than compete with it.
Each iteration reduced a different kind of risk.
The first prototype proved the core interaction, but it also exposed several ways the experience could mislead users even if the interface itself felt clear.
I used each iteration to reduce a different kind of risk: making the number easier to interpret, showing where it came from, exposing uncertainty, and making the assumptions behind the recommendation more visible.
Comprehension risk
Could users understand what the number represented, and what it did not?
Trust risk
Could a confident-looking interface make an estimate feel more certain than the underlying data justified?
Decision risk
Could the product unintentionally encourage spending based on incomplete or outdated information?
Interaction risk
Were assumptions, exclusions, and edge cases visible at the moment they actually mattered?
The goal wasn’t to make the prototype feel more polished. It was to make the guidance safer, more transparent, and easier to question.
V1V2V5A reassuring answer can still be the wrong answer.
The most dangerous version of this product isn’t one that looks confusing. It’s one that looks convincing while giving someone false confidence.
That shifted the design question from: How do I make the answer feel reassuring? to:
How do I make the limits of the answer visible enough to support a responsible decision?
EARLIER DIRECTIONA confident recommendation made the product feel decisive, but could imply more certainty than the underlying data justified.
REVISED DIRECTIONI made uncertainty and contributing factors more visible so the recommendation felt explainable rather than absolute.
Trust comes from calibrated confidence, not confident-looking UI.
The harder feasibility problem was upstream of AI.
Once the interaction model was working, the biggest feasibility question wasn’t whether AI could generate a recommendation.
It was whether the product could obtain reliable, structured, current financial data about income, recurring obligations, taxes, account balances, and irregular expenses and know when that data was incomplete.
In other words, the hard problem sits upstream: data quality determines whether the intelligence is trustworthy.
Manual / synthetic data
Normalized financial data
Input snapshot + rules version
Deterministic forecast engine
Structured scenario result
Numeric validation
Templated explanation / narrow future language layer
User review
Auditing
The recommendation layer only becomes useful once the underlying financial inputs are reliable enough to support it.
What I would test next
Comprehension
Do users understand what “safe to spend” includes and excludes?
Trust calibration
Do users treat the recommendation as guidance rather than a guarantee?
Behavioral value
Does the model actually change a meaningful financial decision compared with checking account balance alone?
I’d test those assumptions before investing in broader functionality.
What this project changed in my AI workflow
The biggest lesson wasn’t that AI made the work faster. I expected that.
What changed was how I use it: generate broadly, challenge aggressively, validate the logic, then narrow with intent.
I now use AI less as a shortcut to an answer and more as a way to increase the number of ideas, edge cases, and implementation paths I can evaluate before committing.
Next project →Increasing multi-product insurance adoption
Designing, launching, and improving a bundled quoting experience across product, pricing, and application complexity.