Split Up
Split Up is a mobile-first expense-splitting app I designed and built end to end, from wireframes to a live product. It's built around the part most bill-splitting tools get wrong: uneven splits, multiple payers, and settling a group in the fewest transactions possible, all wrapped in an interface that never makes the user do math they shouldn't have to.
Overview
Split Up is a mobile-first app for splitting shared expenses among friends: dinners, trips, rent, groceries, the cab home. It's built for 20 to 35 year olds in India, priced and worded in rupees, and shaped around one promise: fast, fair, transparent, settled. Enter your name, add a bill, mark who's in, and the app works out the fewest payments that make everyone even. One guiding rule runs through all of it: simple by default, flexible when it needs to be.
The Challenge
Splitting money with friends is rarely a math problem. It's a social one. Someone floats the whole bill, everyone means to pay them back, and the follow-up feels awkward enough that it quietly gets dropped. The tools that exist treat it like accounting: sign up, create a group, keep a ledger. That's far too much weight for settling a ₹600 dinner on a Friday night.
There's a fairness problem underneath too. An equal split is easy, but it's a small lie the moment one person only had a chai while another ordered half the table. Charge everyone the same and it's simple but unfair. Track every item and it's fair but a chore.
The brief was to hold both at once: something quick enough to finish at the table, fair enough to handle the person who barely ordered, and clear enough that nobody has to argue about who owes what.
Research & Insight
Split Up started as a full UX exercise, personas, journeys, information architecture, wireframes, and a visual direction mapped in Figma before I built the product. A few insights set the direction.
The friction is social, not arithmetic. People can do the division. What they avoid is the "hey, you still owe me" conversation. The product's real job is to make settling feel neutral and automatic.
Equal is right until it isn't. Most splits are even, so equal has to be one tap. But the salad-versus-feast case is exactly where trust breaks, so item-level fairness has to be there without taxing the common case.
Sign-up kills casual use. Nobody makes a friend download an app and create an account to square up a cab fare. Getting in has to cost nothing.
Too many payments is its own confusion. Five friends and four bills can spiral into a dozen little transfers. The fewest payments possible is what actually feels settled.
Then I did the scrappy but important part. Once there was a working prototype, I instrumented it with client-side event tracking and watched real people, friends, actual dinners, actual awkward money moments, split real bills. That's where my own assumption cracked. I'd quietly treated an equal split as basically the whole product, everyone owes the same, done. But people kept reaching to charge one person for just their item, the one who only had a chai while everyone else feasted. Equal wasn't fair, it was just easy for me to build. And watching my own tracking, I caught a payer-selection bug sitting in the settlement logic, the part that decides who owes who. So item-level fairness became a first-class feature, equal stayed the one-tap default, and I fixed the settlement flow.
I'm honest about the limits. It's my own product, so I'm the most biased observer in the room, and my testers were friends, a tiny, non-representative sample who might just be telling me what I want to hear. The tracking showed me what they tapped, not why, and there was no A/B or long-term data, so I can't claim this version "won," only that it matched how people actually feel about money between friends. To take it further I'd recruit strangers, add structured interviews for the why, and run a real experiment on the settlement flow. But even a scrappy round did its job, it killed a lazy assumption before I shipped.
Product Strategy
Every choice traces back to the research.
Simple by default, flexible when needed. Equal is right until it isn't, so equal split is the fast path and custom is one step away, as deep as by-item, so a person who had one dish is charged for that dish and nothing more.
No account, no storage. Since sign-up kills casual use, you enter a name and you're in. Nothing is saved to a server or the device, and closing the tab clears the session by design. It stays a quick tool, not a data trust.
The Split as the container. Bills group into a Split for a trip or event, like a Goa trip that holds every dinner, cab, and stay, so a weekend reads as one settled story instead of scattered receipts.
Fewest payments, always. Because too many payments is its own confusion, the app nets each person out across the whole Split and resolves it into the smallest set of transfers by matching the biggest debtor to the biggest creditor.
Fairness built into the rules. You always appear as "You," you can't accidentally remove yourself from a bill, renaming yourself updates every past split, and two "Goa Trip" entries auto-number so nothing is ambiguous. This is also where the settlement bug I caught got designed out.
Restraint as trust. The friction is social and money is sensitive, so no gradients, no glassmorphism, no decorative noise. A money app has to feel calm and dependable, so the visual direction stays deliberately quiet.
Experience Architecture
The flow makes the fast path fast and the fair path close, on a five-item bottom nav: Home, Splits, Add Bill, History, Profile.
The way in. A welcome screen leads to a single question, "what should we call you?", which sets you as the current user. That's the entire sign-up. From there you land on Home.
The core action. Add Bill sits at the center of the nav because it's the whole point. You scan a bill or enter it by hand, name it, set the amount, and choose who's in and who paid. Then you either drop it into an existing Split, start a new one, or skip the grouping entirely. Last comes the method: split it equally, or go custom by flat amounts or by items.
Seeing it settle. A Split gathers its bills and shows the resolved outcome: a short list of who pays whom, each marked pending or paid. Home frames the day above it, surfacing what you owe and what you're owed at a glance. History keeps the record of past Splits, and Profile is where you rename yourself, with the change rippling through everything you've already logged.
Interface System
The visual system serves the "restraint as trust" finding, calm and quiet, and built so the number you care about is never something you hunt for.
Foundation. A cool near-white canvas with white surfaces and a single indigo primary (#4F46E5) for identity and action. Everything is driven by design tokens defined once, so spacing, radius, and color stay consistent screen to screen.
The amount leads. The rupee figure is the loudest element on any screen, set at 32px bold, so the number you care about is never something you have to hunt for.
One typeface, one rhythm. Inter carries the entire product across a fixed type scale, with a steady 20px margin and section gutter giving every screen the same measured pace.
Color with meaning, never alone. Green marks success, red marks destructive actions, and status is always carried by text or an icon as well as color, so state stays legible for everyone.
A small, honest kit. Cards, a summary card, participant chips, settlement rows, a bottom sheet, status badges, and designed empty states make up a tight component set. Nothing decorative, everything with a job.
Outcome
Split Up shipped as a polished, deployed product taken end to end by one designer, from the research and system work in Figma (personas, journeys, IA, wireframes, and a full design system) through to a working React build live on Vercel, and through a scrappy validation round that reshaped it before launch. The genuinely hard parts land cleanly: item-level fairness that doesn't slow the common case, and a settlement that collapses a messy weekend of shared bills into the fewest payments that make everyone even.
It's honest about its scope. This is a product-design prototype, not a payments product, so there's no banking or real money movement behind it, and state is intentionally ephemeral. The research behind it was lean too, my own product, tested with friends, so I hold the findings as directional, not proven. What it proves is the thinking: that splitting money with friends can be fast at the table, fair to the person who barely ordered, and transparent enough that the awkward part just disappears, and that even a small, honest study is enough to kill a lazy assumption before it ships.
