Payments
Bills & Recharges
IOS & Android
Bills for the whole household, not just you.
Most apps let you pay a bill. We designed one that knows who you live with.
Role
Product Designer
Platform
iOS & Android
Status
approved · in development
Year
2026
CONTEXT
why should we build this?
MyGate already handles a household's money once a month. Residents pay society dues and rent inside the app, so payments were a proven surface, not an experiment.
Utilities were the natural next step. Electricity, gas, broadband and FASTag are the most frequent, most habitual payments an Indian household makes. They are also the only ones that repeat every single month without fail.
That made them strategically interesting. A society due brings a resident back once a month. A stack of utility bills brings them back with a reason to stay. It turns an app people open for visitor approvals into the place they manage their home's money.
Product validated the business case, and it held up. Then it reached me, with one thing left unanswered: why would anyone actually use it?
27 Lakh
Active flats on Mygate, the households this could reach
29%
Of all BBPS volume in India is electricity alone
12x
A year a household pays its electricity bill. Predictable, and habitual
₹2 Cr
Projected annual revenue at maturity
THE CHALLENGE
why would anyone pay a bill here?
Google Pay, PhonePe, Paytm and Amazon Pay all offer bill payments. They are fast, free, and often pay you to use them. A resident opening MyGate to pay an electricity bill would be choosing the harder path for no reason.
Competing on the payment itself was a losing position. Cashback gets outspent. A slicker checkout gets copied within a quarter. Anything bought with a marketing budget is not a reason to exist, it is a reason to leave when the offer ends.
So the design problem was not how to build a bill payments flow. It was finding something MyGate could do that a payments app structurally cannot, and building the product around that instead.
USERS & GOALS
We were designing for a flat, not a person
MyGate's unit has never been the individual. It is the home, and the people who happen to live in it. So the question was not who our user is, but what shapes a flat can take, and what each one needs.
Ramesh
Owner, lives in the flat
HOUSEHOLD
Malithi
Aryan
Ramesh pays every bill in the house. His wife has no idea what is due until he mentions it, and he forwards screenshots when she asks. The money is shared. The information is not.
Shared awareness, without forwarding screenshots
Suresh
Tenant, moved in this month
HOUSEHOLD
Rekha
Suresh has to pay the flat's electricity bill, but the connection is in the owner's name and he does not have the account number. His first month started with a text message asking for it.
The rented flat's bills, without the archaeology
Diljit
Flatmate, shares a rental with flatmates
HOUSEHOLD
Karan
Harsh
Three colleagues splitting rent. The electricity bill is genuinely both of theirs. Diljit's credit card bill is emphatically not, and he would rather it never appeared on a screen Karan or Harsh can open.
A hard line between shared and personal
Prakash
Owner, rents the flat out
HOUSEHOLD
Lives elsewhere
Prakash still shows up on the flat in MyGate. He would like to know the electricity connection in his name is not being neglected. He has no business seeing what his tenants spend.
Assurance, without intrusion
These four shapes are the whole design brief. A model that works for a family and breaks for two flatmates is not a model, it is a guess. Everything about visibility, ownership and defaults had to hold in all four.
What the users need
Pay a bill without hunting for account numbers
Know what the home owes, and when
See who paid, without asking
Keep personal bills personal
What the business needs
Convert existing payment behaviour into a monthly habit.
Unlock a recurring transaction from an existing user
Prove adoption before heavy investment
Build a reason to open MyGate that isn't a visitor
OPPORTUNITY
could we even get residents here?
Before deciding what to build, we had to know whether anyone would arrive. A differentiator is worthless if the product sits somewhere nobody looks.
So early on, alongside the business validation, we mapped where a resident could plausibly encounter this inside an app they already open for other reasons. Not as a launch plan, but as a test of whether the opportunity was real. If every entry point had to be a banner shouting at people, the answer was probably no. It was not.
01
Discovery, for residents who transact but have never
seen this
A permanent home screen entry point beside Payments, and bill keywords in the global search they already use.
02
Cross sell, at a payment they already trust
The moment someone finishes paying society dues is the moment they are most receptive to paying another bill. The dues empty state was sitting unused.
03
Recall, for the bill that is about to be late
A pending bill surfaced on the home spotlight, and due date reminders. The reason to come back next month.
04
Move in, the highest intent moment there is
A new resident setting up their flat is already handling gas, electricity and rent. The flat's own bill history is waiting for them.
Two things came out of this. First, the opportunity was real: residents could be reached at moments where paying a utility bill continues what they are already doing, rather than starting a new decision. Second, and more usefully, the move in moment pointed straight at the household. A new tenant needs the flat's electricity account number, and the flat already knows it. That thread runs through everything that follows.
The screens came much later, once there was a product to point at.
Discovery
A permanent entry point beside Payments and Amenities.
Cross sell
Surfaced right after a payment the resident already trusts.
Recall
The pending bill closest to its due date, with Pay Now.
Reach
Bill keywords in global search, plus due date reminders.
IDEATION
exploring what could set it apart
We started unconstrained. Every idea that could differentiate this product went on the table with the team, before anyone asked whether we could build it.
"What if bills had a calendar? See the whole month at once."
"Split the electricity bill with your flatmates."
"Rewards. Coins. Cashback on every bill."
"Streaks for paying on time. Build the habit."
"Bills that belong to the house, not one person."
"Show the household where its money goes."
These did not stay as words. I sketched individual screens for the promising ones, not full flows, just enough to see where an idea would sit. Rendering an idea is the fastest way to learn whether it is actually interesting, or whether it only sounded interesting in a room.
The constraints arrived
We had a timeframe, a limited build budget, and one blunt question: what proves adoption before we invest heavily? Not the most features, the minimum lovable product. I judged each idea on novelty, whether the market had already done it, and feasibility, whether we could build and sustain it.
IDEA
NOVELTY
FEASIBILITY
Rewards and loyalty
Expensive to sustain and trivially copied. It could buy a first transaction, but it could never anchor the product.
Partly used · a first payment offer, not the foundation
Split expenses with flatmates
Genuinely useful, and it serves the multi-tenant use case. But multi-tenants are only a small % and UPI already solves splitting, and it was not what would win the first transaction.
Deferred · future scope
Payments calendar
Improves the product without differentiating it. Anyone can add a calendar.
Discarded for now
Streaks and gamification
Decoration layered on a payment. It does not change what the product is for.
Cut from scope
Shared household bills
No payments app is built around a home. MyGate already models the flat and everyone in it.
Kept · became the product
Household spends
Sharing needs a payoff. A category breakdown of where the home's money goes, expandable later.
Kept · the reason to share
Direction
Reframing the problem
FINAL DESIGN
over to figma…
Let's have a closer look
reflections & learnings
The differentiator was context we already had, not a feature we could add. The moat was never a payment capability. It was knowing who lives in the flat.
Sketching is how I judge an idea, not how I finish one. Rendering a concept early tells you whether it is actually interesting, or whether it only sounded interesting in a meeting.
A new pattern competes with habits your own app has taught. Our bill flow was fine in isolation and wrong next to society dues. Users showed us that. We did not reason our way to it.
Protecting users by removing their choices is the easy argument to win. Defaults should be safe. Doors should still open.