Case study · End to end

Split bills without hitting a wall.

An expense-sharing app I designed and shipped on web, iOS and Android. It stays free, has no limits, and works wherever you are.

  • Design & researchMy role
  • 3Platforms
  • 400+Users
  • 100Active groups
SplitMaadi on mobile: the same group, with the amount you need to pay shown first

Why I built it

01 — Problem

It started with a limit.

Splitwise, the app I used with friends, began capping how many expenses I could add per day. A shared dinner became a queue.

I assumed replacing it would be easy. Expense splitting isn’t new. But when I actually tried the alternatives, the product I wanted was hard to find.

The closest options were the split features inside PhonePe and Paytm. They worked, but splitting wasn’t their main job. The feature sat several taps deep, desktop support was thin, and I couldn’t trust that receipts and history would still be there in a year.

That was the point where I stopped looking and started building.

My list was short
  • No cap on expenses I can add
  • No ads
  • No odd restrictions on attachments
  • My history stays available
  • Fast and low-friction
  • Works on every device I use
First I looked at what already existed.

What already existed

02 — Competitive analysis

The closest alternatives were the expense-splitting features built into payment apps like PhonePe and Paytm. They were usable, but only up to a point. Desktop support was almost non-existent, and attachment history wasn’t something I could rely on — these apps delete it after a few months.

  1. Finding 01

    Simple user experience

    Adding even a simple expense took too many clicks, mainly because the feature sat deep inside the app.

  2. Finding 02

    Cross-platform support

    Sometimes I add an expense on my phone, then want to check balances on my laptop. Cross-platform was a requirement, not a nice-to-have.

  3. Finding 03

    Attachments handled properly

    Expenses aren’t always just numbers — people need to attach receipts or images for reference.

How SplitMaadi compares with the alternatives across five features
FeaturesUnlimited expensesAd-freeDesktop supportPersistent historyLocalized UI
SplitMaadi
Splitwise
PhonePe
Paytm
So I turned that list into four rules.

Four rules I held every decision to

03 — Insight
  • 01

    Don’t limit the core use case.

    If the product exists to add shared expenses, users should never think about how many they’re allowed.

    Shaped the whole product: no caps anywhere.

  • 02

    Cut friction, not features.

    Adding an expense should take seconds.

    Shaped Decision 01 and Decision 02

  • 03

    Receipts are part of the expense.

    A bill photo is context, not an attachment bolted on afterwards.

    Shaped Decision 02

  • 04

    Be wherever the user is.

    I add expenses from my phone and check balances from my laptop. Cross-platform is a requirement, not a bonus.

    Shaped Decision 01

And one commitment underneath all four: the basic product stays free.

First test: getting friends into a group.

Getting people into a group

04 — Decision 01
Held to
The problem

The first version added people by email. That’s clean to build and awful to use. Nobody remembers six friends’ email addresses, and asking for them at a dinner table is exactly the friction I was trying to remove.

What I considered

  • Contacts access

    Rejected

    Fastest once granted — but it means a permission prompt before they’ve split a single bill, and it asks for far more than the task needs.

  • Phone-number lookup

    Rejected

    Familiar from UPI apps, but it forces phone numbers as identity and doesn’t help on desktop.

  • Suggest past people

    Shipped

    If someone was in a past group, offer them. No typing, no remembering.

  • QR join

    Shipped

    When people are physically together — a trip, a dinner — one person shows a code, everyone scans. Done.

What I shipped

Suggestions plus QR, with email kept as the fallback for someone new and remote.

The trade-off

One flow became three. Internally that’s more states, more edge cases, more to test. I accepted that cost because the complexity moved from the user’s head into the product — which is where it belongs.

The first version: an Add a new member sheet asking for a name and an email address
Before — email only

Select a ring to see the reasoning.

The shipped version: an Add members sheet with recent friends to tick, plus Share invite link and Add by email at the bottom
After — suggestions, invite link, email

Select a ring to see the reasoning.

Next, the same idea on every other screen.

Never make someone repeat themselves

05 — Decision 02
Held to

Don’t make users remember, type, or repeat anything the product can carry for them.

  • Settling up

    Save UPI details once; every later settlement is one tap.

  • Receipts

    Attach a bill and pull the amount from the image instead of retyping a number that’s already in the photo.

  • Recurring expenses

    Rent, groceries, subscriptions. Mark an expense as recurring once and never enter it again.

  • Sign-up

    Ask only for what’s needed to get inside. Everything else can wait until it’s useful.

New Expense screen: a receipt photo attached under Attachments, the total already filled as 1750 from it, and a Repeat option below
Receipt attached
Amount pre-filled
Recurring toggle

Select a ring to see the reasoning.

Then I sat five people down with it.

From friction to flow

06 — Design evolution

I wanted the app to feel polished and low-effort, so I sat with five students and working professionals and watched them use it. Their words drove three rounds of changes.

Round 01

Create new expense

  • Pain point

    “Screen feels dense and form-heavy.”

  • Pain point

    “I wasn’t sure where to tap to upload the receipt.”

  • Pain point

    “I had to squint to see the amount, and the primary button lacks importance.”

The first Edit Expense form: name, amount and description fields, a small attachment thumbnail, paid-by and split-by controls, and a small Edit button at the bottom.
Before
The redesigned New Expense screen: the amount shown large at the top, then expense name, note, a large dashed Add Receipts area, and a full-width primary button.
After
  • 01

    Reduced visual clutter and tightened the hierarchy, so the form feels lighter and quicker to complete.

  • 02

    Attachments became a large, obvious drop-zone area labelled Add Receipts.

  • 03

    The Create button is now visually dominant and sits where people expect to finish the task.

Round 02

Group expenses

  • Pain point

    “I’m not sure why I need to see the total group spend.”

  • Pain point

    “I’m mainly trying to figure out whether I need to pay someone, or if I’ll get money back.”

The first group screen: a Total Group Spend card above group balances and the list of expenses.
Before
The redesigned group screen: a You need to pay card showing the amount owed and a Settle now link, above group balances and the expense list.
After
  • 01

    Removed the Total Group Spend block — it didn’t serve the main goal.

  • 02

    The screen now leads with whether you have pending dues or are settled up, so your position is clear at a glance.

Round 03

Settle up

  • Pain point

    “I know I owe money, but there’s no clear action to settle the payment.”

  • Pain point

    “This page feels almost empty.”

  • Pain point

    “Who do I owe money to, and how do I settle it right now?”

The first Settle Up sheet: a single row showing the person owed and the amount, with no action button and a large empty area below.
Before
The redesigned Settle Up sheet: a Total you owe card with a pending badge, then the person owed and a full-width Settle Up button.
After
  • 01

    Added a Total You Owe block showing the pending balance up front.

  • 02

    The redesigned card carries a Settle Up button, so the next step is obvious.

  • 03

    People can scan the screen and act on it in one pass.

Then I shipped it and watched what people did.

What users actually did

07 — Evidence

Groups are the foundation — you can’t split without one. So the first surprise in the analytics was where people stopped.

  1. 400+ signed up
  2. Half never got here
  3. 200 created a group
  4. Half went quiet
  5. 100 groups active today
Alongside that
  • ~25%turned notifications on
  • 3 in 10sign-ups stick around
  • 50%of groups go quiet

First read vs. second read

My first read was “they don’t want these.” My second read was better: the interface was simple, but the next step wasn’t obvious. This wasn’t a demand problem. It was a discoverability and timing problem.

So I changed when the product asks

The review prompt moved from “soon after install” to right after a successful settlement. Notification permission is now asked when the user has a live group with money owed — a moment when a notification has an obvious reason to exist.

The question isn’t “how do I make users do this?” It’s “at what moment is this action useful to them?”

Which changed what I’d fix first.

What I’d change first

08 — Next

The first-time experience. A simple interface isn’t enough — the first outcome has to be obvious. I’d rebuild the first session around one path:

  1. Step 1

    Create a group

  2. Step 2

    Add an expense

  3. Step 3

    See who owes what

Everything else — notifications, receipts, recurring, settings — would appear progressively, when it becomes relevant. The funnel is how I’ll judge it: the share of new users who create a group in their first week, before and after.

Second: the groups that go quiet. Some of that is natural — a trip ends, the bills are settled. But some is probably a group that never got its second expense. Understanding which is which is the next research question.

09 — Takeaway

Simple isn’t the same as obvious.

I’d optimised every screen for speed and still watched half of all users miss the one step that makes the product work. The fix wasn’t more design — it was better timing. Now every “I think users will…” has a follow-up: “…and here’s how I’ll know.”

Next case study

ReadHalo