# Gig Worker Fintech: product design case study Financial Clarity for India's Gig Economy. Money tools for people paid in small, uneven amounts. By Krishnachandran Ramachandran (Kaezee), end-to-end product designer. Page: https://kaezee.com/work/paisev - **Product:** Paisev - **Role:** Product Design, UX Research - **Team:** Solo - **Focus:** Strategic Design Exercise, Behavioural Design, Underserved Markets - **Timeline:** 3 months - **Platform:** Mobile app (concept) - **Status:** Concept - **Domain:** Fintech · budgeting for irregular income **TL;DR.** India had 12 million gig workers in FY25, and a fifth of its workers are casual labourers, yet every money app they are offered assumes a salary. Paisev is a concept for people paid in small, uneven amounts: it finds each payout through the bank, splits it into pots you can see the maths for, and never moves your money, like a friend who keeps count. It is speculative: built from public data and informal chats, not tested with users, and the untested parts say so. --- ## Paid in pieces, budgeted like a salary A delivery rider in Kerala gets paid once a week, and never the same amount twice. A painter gets paid at the end of each job. Their rent is the same every month. Banks want a minimum balance they can't always keep. Budgeting apps ask for a monthly limit. None of them start from the way these people are paid. What would help them is a friend who keeps count. - **12M** Gig workers in India, FY25 - **40%** Of them earn under ₹15,000 a month - **~₹920** A day's construction wage in Kerala, about twice India's - **20%** Of India's workers are casual labourers Sources: Economic Survey 2025–26; RBI, Handbook of Statistics on Indian States 2024–25; MoSPI, Periodic Labour Force Survey 2025 ### Where this started Paisev began with a friend who worked in quick commerce, and what the job was really like. Then I asked cab drivers and quick-commerce riders about their work, in informal chats, before turning to the public data. **Who did what.** This is a solo concept. I did the research, the design and every screen. #### The approach, step by step *Figure: Public data for the numbers, chats for the questions* ### How the money arrives Every kind of gig and trade work pays differently. What they share is the shape: small amounts, on their own rhythm. *Figure: Seven ways of being paid, and what the people doing the work told me. The figures are ballpark estimates: they vary by city and change often* Cab drivers told me they make ₹2,000–3,000 a day. After costs, much less of it reaches home. #### Where a ₹2,500 day goes *Figure: An estimate: the fares from my chats, the costs from a survey* - **68%** Of cab drivers say their expenses are higher than their earnings - **83%** Work more than 10 hours a day Source: PAIGAM & University of Pennsylvania, “Prisoners on Wheels?” (2024), a survey of 10,384 cab and delivery workers in 8 cities ### Banking isn't built for this *Figure: What banking assumes, and where the saving happens instead* ### Where Paisev fits Plenty of products help people save. None of them start from small, uneven pay, and most move the money somewhere else first. *Figure: How people in India save today, and the gap Paisev is built for* ### Four ways of being paid Paisev is a concept, so these are proto-personas: built from public data and informal chats, not from interviews. Each one is an assumption to check. - **The courier** Paid weekly (figure: The courier: a delivery rider with his bag's straps over his shoulders) Rent is the big worry. - **The cab driver** Paid per ride (figure: The cab driver: a driver holding his phone in both hands, a new ride and its fare showing in a callout) Cash has to count too. - **The freelancer** Paid in lumps (figure: The freelancer: working on a laptop) One payment has to last. - **The painter** Paid per job (figure: The painter: a painter in a cap holding a paint roller in one hand) No job, no income that day. Proto-personas, after Nielsen Norman Group's “3 Persona Types”: assumptions to validate; none are findings yet. ## Pots, on money that never moves Each payout is split into pots: rent, bills, emergency, goals. The pots are labels on the rider's own bank balance. Paisev never holds or moves the money. #### Decision 1: Find the income through the bank, after reading SMS was ruled out. *The cost:* It needs a regulated partner and it isn't instant: the bank is checked a few times a day, so a payout can take hours to show. Pots only work if the app knows when money lands. That had to be solved before any screen was drawn. *Figure: Why SMS was dropped, and what the bank-data route decided* *Figure: A first payout from a new sender, and the question it asks* #### The consent request, where the data goes, and the path every payout takes *Figure: The consent request, in plain words* *Figure: Money never moves: only data, with consent, crosses the line* *Figure: Each payout's path, and the three ways off it* #### Decision 2: A ledger: pots are labels on your own balance. *The cost:* Paisev can't stop anyone spending pot money. The label has to do the work. People treat money differently depending on what it's for. That's mental accounting, and the label does the work wherever the money sits. So nothing moves, no licence is needed, and there are no fees. The idea behind pots has been tested with people close to these personas. Labourers in rural India who split their savings into two envelopes saved far more than those with one. *Figure: Split money gets saved; one pooled pot breaks* *Figure: The home card: available to spend is the bank balance minus the pots* #### Using money from a pot *Figure: Using money from a pot: the label moves, the money doesn't* #### Decision 3: Every split shows its amounts and its maths before anything is saved. *The cost:* More to read on every payday, and a confirm step that a one-tap split wouldn't need. Each pot's share comes from what it still needs, divided by the payouts left before its date. High-priority pots with the nearest dates go first. What's left is spending money. *Figure: The split: every amount and its reason before anything is saved* #### The options weighed, a new pot, and undo *Figure: The middle way: the app does the maths, the user decides* *Figure: A new pot shows the working behind its weekly amount* *Figure: After the split: done, with undo* #### Decision 4: Calm colours with one job each, and no red for being behind. *The cost:* No alarm to lean on: a pot falling behind has to be noticed from a calm amber note. - **#0F766E** Action: buttons, links, selection - **#6AF9C9** Money in, on track (fill only) - **#FFC563** Attention: due soon, behind - **#FF8888** Problem: real problems only - **#66BFFF** Tips and explanations *Figure: A pot that has fallen behind: amber, never red* #### Decision 5: Plain words, in the user's own language, light enough for any phone. *The cost:* Every line is written three times and still has to fit, and there's no rich visual layer to lean on. The copy does most of the work here: many users don't read English comfortably, many are older and wary of scams, and most are on budget phones. - **49%** Of adults can bank online - **₹22,846** Crore lost to cyber fraud in 2024 - **57%** Of phones sold in 2025 cost under $200 Sources: MoSPI, Comprehensive Modular Survey: Telecom 2025; Ministry of Home Affairs, Lok Sabha reply (Dec 2025); IDC India, CY2025 *Figure: Language first, then weight, words, safety and timing* #### Front to back: the service blueprint The whole service on one board: what the user sees, what runs behind it, and the moments where someone wary of scams decides whether to trust it. *Figure: Service blueprint: what the user sees above the line, what makes it work below it, and where trust is won* ### The hard days The plan has to hold up in a bad week too. These are the rules for when the week goes wrong. *Figure: The rules for the hard days, from the design's own spec* #### A cash day, in the app *Figure: Adding cash income: quick amounts, and cash counted as earnings but not as money in the bank* #### All the screens *Screen: Home* *Screen: A payout found* *Screen: Split your payout* *Screen: Split done* *Screen: Pots* *Screen: Linked accounts* ## A concept, and the tests it needs Paisev wasn't built or tested, so there are no results to show. Below is what it assumes, and how I would test each assumption. *Figure: A north star, with its leading signals and guardrails* *Figure: Importance against evidence: the top-left gets tested first* #### The test plan *Figure: Six people, three tasks, and what each result would change* ## The engine came before the screens - Learned **Detection comes first** Pots depend on the app knowing when money lands. Getting that wrong would have broken every screen after it. - Learned **Rules can shape the design** Google Play's SMS rules and the Account Aggregator framework ruled things out, and what was left was simpler and safer. - Learned **The saving already happens** People already save in their heads, in chit funds and in groups. The product only has to write that down. - Next time **Test the assumptions first** Whether riders will link a bank at all comes before any screen polish.