FinTech
SaaS
Landed
Know what’s actually safe to spend. A case study — solo product design + AI-assisted build, from problem to tested prototype.
Auth, onboarding, Home, Money, Reports, Payments, Settings — fully click-through with realistic mock data. Best viewed on mobile width, even in a desktop browser.
Overview & Role
What
A mobile-first fintech app for people whose income isn’t a fixed monthly paycheck
Tools
Claude (brainstorming, research synthesis), Figma Make → Claude Design (UI), Claude Code + Supabase (planned backend), Claude in Chrome (automated QA)
Role
Solo — product thinking, UX/UI design, design system architecture, AI-feature design, prompt-engineering the build, and QA
Status
Phase 1 complete — fully designed, interaction-tested prototype. Backend intentionally deferred to Phase 2.
Constraints
Solo project — no team or dedicated QA. One round of real survey data. Deliberately no bank-linking by design. Backend deferred to optimize for validating product and interaction design.
The Core Problem
Mainstream finance apps assume income is fixed and monthly, so they only need to track spending. For freelancers, gig workers, business owners, and anyone with variable income, that assumption breaks — obligations are fixed and dated, but income is not.
The result: a recurring, specific anxiety — “I have money in my account right now, but is it actually mine to spend?”
Core insight and app tagline: Money you\’re owed is not money you have.
Target Audience
Not freelancer-only — anyone whose inflows are irregular while outflows are fixed: freelancers, gig workers, commission-based sales roles, small business owners, seasonal workers, and salaried employees with meaningful side income.
Primary test persona: Meera, 29, freelance designer — irregular client payments, fixed EMI/rent/SIP, anxious about whether money in her account is genuinely spendable. Testing rounds added personas across the spectrum (salaried + side income, small business owner) to pressure-test the app outside its most obvious use case.
Key Research Insights
Competitive analysis (PocketGuard, SenticMoney, YNAB, Lucky Friday, Monarch Money) found real market whitespace: no competitor combines received-only income counting + savings-as-a-claim with withdrawal friction + dateless optional spend logging + deliberate minimalism.
A 9-response validation survey delivered one strong confirmation and one real correction:
✓ Confirmed
The core mechanic — “money only counts once landed” — got unprompted, unanimous agreement. Strongest signal in the dataset.
⚠ Changed Design
Mandatory friction on savings withdrawals tested poorly. This changed the design: withdrawal confirmation became a Settings toggle, default ON, rather than a fixed rule.
Brainstorming & Ideation
The product went through substantial reasoning before a single screen was designed:
The formula evolved twice — from a “stated bank balance minus obligations” model, to a waterfall model (income received → expenses → savings → everyday spending → remainder = Safe to spend) — removing the need for manual balance entry entirely.
Savings were deliberately modeled as a claim on money, not a category — reducing spendable balance automatically, requiring deliberate action to reverse.
Explicit non-goals locked in early: bank-linking, tax estimation, ML-based prediction, multi-currency — all named and rejected on purpose, to protect the
Design Decisions & Pivots
Three-tier design system (primitives → semantic tokens → components), built deliberately portable across Figma and Claude Design. Warm neutral base with a single amber accent, reserved only for the one number that matters.
Real pivots, driven by evidence — not aesthetics:
Pill buttons → 8px radius matching inputs
Deliberate trade against the “textbook Material” look, for visual consistency.
Centered modals → bottom sheets, system-wide
For thumb reachability on mobile-first experience.
Balance-anchored → income-waterfall calculation
Manual balance updates created an unresolvable trust conflict. Mid-project tool pivot: Figma Make → Claude Design, requiring re-packaging the entire design system as a portable spec.
Savings withdrawal: mandatory → optional toggle
Directly from survey data — majority said “annoying” or “depends,” zero said “helpful.”
User Flows & Prototype
Splash → Welcome (Create account / Log in) → Email + OTP (no password) → Minimal onboarding (two optional fields only) → Home, with Money, Reports, and Payments reachable from bottom navigation. Every destructive or confirming action routes through the same bottom-sheet pattern, never a blocking modal.
Fully click-through prototype covering: Auth, Onboarding, Home (live Safe-to-spend, spend logging, recent activity), Money, Reports (AI-generated summary), Payments (due-date checklist), Settings, and an in-app Notifications system — all wired to realistic mock data.
Micro-interactions & Key Features
Live-updating Safe to Spend
Recalculates instantly on any income, spend, or withdrawal event.
Buffer-Dip Warning
A bottom sheet that intercepts a spend before it crosses a self-set safety cushion — not a blocking rule.
Status Progression Badges
Quoted → Invoiced → Confirmed → Received — gating exactly when money becomes “safe.”
Undo Toast + Editable Everything
Undo toast on every logged spend. Every entry supports edit/delete with correct recalculation everywhere it appears.
AI Guardrails & Security
AI never calculates — the one AI feature shipped (a plain-language monthly report summary) only narrates numbers the app has already computed deterministically. It cannot invent or estimate a figure.
No advice, ever — descriptive language only, never “you should,” for both tone and liability reasons. Fails silently, not loudly — if the AI call fails, the numeric report still renders with no broken text.
Auth: email + OTP only, no password. Input hardening: every amount field capped (₹1–₹1,00,00,000), every text field length-limited, pure-numeric “notes” rejected to prevent silent data-entry errors.
Testing & Validation
Seven full rounds of structured, persona-driven AI QA — each with a distinct persona (freelancer, business owner, salaried+side-income), progressively more adversarial: boundary values, rapid-tap race conditions, narrow-viewport stress tests, and full data-volume tests (15–20 recurring items).
Round 1 found a critical trust-breaking bug — Home and Reports disagreed on the one number the whole app exists to protect. Rounds 2–6 systematically closed every functional bug. Round 7 confirmed zero outstanding bugs, including full regression coverage after a system-wide visual refresh.
What held up through all seven rounds without ever failing: the core Safe-to-spend calculation, exact boundary enforcement, and zero data loss under rapid/adversarial interaction.
What\’s Next
Immediate next phase: connect Supabase via Claude Code — real accounts, real persistence, replacing the current mock-data prototype. Then, three AI features, scoped and sequenced by risk and effort:
1
Natural-language quick-add
“Spent 500 on pizza” parsed into structured data.
2
Receipt/bill photo scan
Same pattern as quick-add, image input instead of text.
3
Ask-your-data chat
Conversational queries, strictly grounded in the user’s real logged data. Held for last — highest risk of the AI inventing a plausible-but-wrong number in a finance app.
Key Takeaways
A single piece of real survey data (the withdrawal-friction pushback) changed the design faster and more convincingly than any amount of internal reasoning could have.
AI-persona QA, run adversarially and repeatedly, surfaced the same class of bugs a human QA pass would — and did it in hours, across seven full rounds.
The biggest risk to a “one trustworthy number” product isn’t a missing feature — it’s two screens quietly disagreeing with each other. That bug, found in round one, shaped how seriously every subsequent round treated cross-screen consistency.
Try the Prototype
Auth, onboarding, Home, Money, Reports, Payments, Settings — fully interactive with realistic mock data.