Meera
It's gone by the 19th and I don't know where.
Needs
A hard stop on the groups she overspends in.
Frustration
One long list with no sense of "how much is left for food".
Pots is a UPI payment app concept. It splits your money into groups, like groceries or gifts, and pauses a payment when a group runs out.
What this project is and what I set out to prove.
Payment apps tell you what you spent after it's gone. Pots stops the payment before it happens.
People already sort money in their heads: this much for food, this much for a partner, this much for me. Payment apps ignore that. Budgeting apps remember it but can't act on it. Pots puts the limit at the moment money moves.
One person's month, told in three messages.
Payment apps move money fast and list every payment in one stream. Budget apps categorise, but only after the spend, and they can't block anything.
Nothing connects a plan ("₹5,000 for groceries") to the payment button. That gap is what Pots fills.
Three methods, one question: how do people keep spending in check today?
| What people need | Typical UPI app | Budget tracker | Pots |
|---|---|---|---|
| Pay by QR, contact or UPI ID | Yes | No | Yes |
| Sort spending into groups | After the fact | Yes | Before you pay |
| Stop a payment at a set limit | No | No | Yes |
| Hide balance until you verify | Whole account | No | Per pot |
Three people, drawn from the interviews.
It's gone by the 19th and I don't know where.
A hard stop on the groups she overspends in.
One long list with no sense of "how much is left for food".
My allowance has to last the whole month.
To see early that a group is nearly empty.
Finding out a payment can't go through only when he's at the counter.
Some of this money is for us, and it's private.
Named pots for gifts and dates that stay hidden on her lock screen.
Balance and history visible to anyone who glances at the phone.
From findings to a design question and a journey that changes.
help people keep to a plan without leaving the app they pay with?
The limit is enforced at payment, in calm language, always with a next step.
Balances stay hidden until you verify. Names stay off the lock screen.
Everyday payments work like any UPI app. Pots add to it and don't replace it.
Value to the user against effort to build.
I scored every idea on how much it helps the person against how hard it is to build, then kept the top-left first. The hard stop is the reason the product exists, so it ships even though it needs more effort than a tracker would.
This is a working model of the core flow. Tap a pot, unlock its balance, and try to overspend.
Demo PIN: 1234. Fingerprint works with one tap.
What the prototype does and why.
The home screen is safe to glance at in public. Exact figures sit behind fingerprint or PIN.
Unlocking is per visit. Going back to the home screen locks every pot.
Nobody types a PIN for a payment that was never going to work.
Top up, borrow from another pot, or pay from the main account. The main account choice is logged.
The label always says the percentage too, so colour is never the only signal.
Scan, contacts, UPI ID, bank, bills and recharge sit in the same place as any UPI app.
The limit check comes before authentication.
The moments that decide whether people trust a limit.
What would need to be true for this to ship.
UPI moves money between bank accounts and doesn't know about pots. In this concept, a pot is a layer inside the app. Your money stays in your linked account, and the app checks the pot's limit before it sends a payment request.
That means limits only apply to payments made inside Pots. A payment made from another UPI app on the same account wouldn't count. A real product would need to explore a bank partnership or the delegated-payment features that UPI is adding. I would verify the current rules before making any claim.
And what I took from it.
The hardest decision was where to put the limit check. Putting it before the PIN felt small, but it changed how testers described the app: from "a tracker" to "something that's on my side".