Mobile Expense Splitter for Groups

A mobile app for tracking shared expenses within a group — a trip, a shared apartment, a dinner club, a team event. Anyone records an expense, assigns participants and a split rule, and the app answers the only question that matters: who owes whom, how much, after everything is netted out? The math is the product: correct balances, clear rounding rules, and a simple settlement plan that minimizes the number of payments.

>A calculation tool, not financial advice. The app performs arithmetic on numbers you enter. It does not advise on money, budgeting, debt, or anything else, and it makes no claims about saving you money.

Who Is This For?

• Students splitting rent, groceries, and group trips
• Housemates tracking shared bills
• Travelers and friend groups managing shared costs
• Beginner developers learning their first real mobile app with a clear, bounded feature set

The Problem

Splitting shared costs is a constant, low-stakes source of friction. Someone pays for the group, and everyone owes them a share — but tracking the chain of “you owe me, I owe them, they owe you” in a notes app is error-prone and forgettable. The two classic failure modes: balances never get settled because the chain is too tangled to compute, and small asymmetries (someone paid more, someone joined halfway) get rounded away unfairly.

How It Works

1. Record an Expense

A group member records an expense: amount, payer, participants, and a split rule:

• Equal split — amount divided evenly among selected participants
• Unequal split — custom amounts per participant (e.g., someone’s meal cost more)
• Percentage split — participants cover fixed percentages (e.g., 60/40)
• Share split — relative weights (e.g., 2 shares vs 1 share) that convert to percentages

The app stores the raw rule, not just the result, so history stays auditable.

2. Rounding with a Rule

Money is integer cents; rounding must be deterministic and fair. For an equal split that does not divide evenly (e.g., $10.00 ÷ 3), the app applies a documented rule — for example, the largest remainder method: everyone owes the floor, and the leftover cents are distributed so the total reconciles exactly to the penny. No rounding drift accumulates across expenses.

3. Compute Balances

Each member’s balance = sum of amounts others owe them − sum of amounts they owe others. A positive balance means the group owes them; negative means they owe the group.

4. Settle with Fewest Transactions

Instead of a fully-connected graph of debts, the app computes a simplified settlement plan. The greedy algorithm (also used by many expense apps):

The result is at most n−1 payments for n people — a plan that is simple, even if it is not always the minimum possible in every exotic case (a known limitation of the greedy approach, documented honestly).

Balances: Ana +120 · Ben -70 · Cal -50 Settlement: Ben pays Ana 70 → Ana +50, Ben 0, Cal -50 Cal pays Ana 50 → Ana 0, Cal 0 Done in 2 payments (n−1 = 2). 

Key Features

• Groups with participants — create a group, invite/name members
• Expense rules — equal, custom, percentage, and share splits
• Deterministic rounding — largest-remainder rule, documented and tested
• Live balances — per-member balance vs. the group
• Settlement plan — fewest-transactions plan with one-tap “mark settled”
• History — every expense is editable/deletable with a recalculation
• Categories — optional tags (groceries, rent, transport) for simple summaries
• Offline-first — the app works with local storage; optional sync later

Functional Requirements

User Stories

• As a housemate, I want to record this month’s shared bills and see one balance per person, so that we settle once instead of chasing each other.
• As a trip organizer, I want to split the Airbnb 60/40 with my co-organizer and everyone else equally, so that the split matches our actual agreement.
• As a group member, I want a settlement plan that minimizes payments, so that I make one transfer instead of four.
• As a developer, I want the rounding logic unit-tested, so that balances never silently drift by a cent.

MVP Scope

Authentication, cloud sync, push notifications, and receipt uploads are natural second-phase additions.

Project Timeline

• Phase 1 — Planning (Week 1): Data model (groups, members, expenses, rules), rounding rule, and settlement algorithm design on paper.
• Phase 2 — Core math (Week 2): Balance engine and settlement algorithm in pure functions, fully unit-tested before any UI.
• Phase 3 — App (Weeks 3–4): Screens for groups, expenses, balances, and settlements; local persistence.
• Phase 4 — Polish (Week 5): Categories, edit/delete flows, and edge-case handling (empty groups, zero amounts, mid-group joins).
• Phase 5 — Testing + Docs (Week 6): End-to-end tests, rounding property tests, and a real group trial.

Testing Strategy

• Rounding tests — amounts that don’t divide evenly always reconcile to the cent (property test across many random splits).
• Balance tests — known expense graphs produce exact net balances.
• Settlement tests — the greedy plan settles every graph to zero and never exceeds n−1 payments.
• Recompute tests — editing/deleting an expense recalculates all balances and plans correctly.
• Persistence tests — restarting the app restores state; sync conflicts (if built) never lose data.
• Pilot test — run a real group trip or shared-month through the app and confirm the plan matches manual math.

Deployment Considerations

• Start as a local-first app: no accounts, no server — data lives on the device with a clear export path.
• If sync is added, make it explicit and optional, with authentication and conflict resolution documented.
• Provide full data export (JSON/CSV) and a delete-all path.
• Publish the rounding and settlement rules in-app so the math is transparent.

Security and Privacy Considerations

• Money data is sensitive. Expense records reveal relationships and habits; store them locally by default and encrypt at rest where the platform allows.
• No financial advice. The app must not suggest budgets, warn about spending, or claim savings — it calculates what you entered.
• Optional sync = authentication. If accounts and cloud sync exist, require real auth, document what is stored, and support account deletion.
• Data export/delete. Users can export and permanently delete their data at any time.
• Local-first honesty. Do not claim “end-to-end encrypted sync” unless you actually build it; offline-first with optional plain sync is the honest MVP framing.

Success Metrics

• Settlement completion: share of groups whose balances reach zero (the app’s core job).
• Rounding correctness: zero reported cent-discrepancies after pilot use.
• Retention: groups that keep using the app across multiple events.
• Pilot feedback: did the settlement plan match what the group expected to pay?

Common Challenges

• Rounding drift — naive per-expense rounding accumulates; the largest-remainder rule applied at the expense level plus exact balance math prevents it.
• Mid-group joins — new participants only affect future expenses; the data model must handle “joined on date” cleanly or the UI must make it explicit.
• Settlement complexity — the greedy algorithm is simple but not always minimal; document the trade-off rather than over-engineering.
• Scope creep — budgets, receipts, and currency conversion are tempting; they belong after the core math is proven.

Learning Objectives

• Model a small domain cleanly: groups, members, expenses, split rules.
• Implement exact money math with integer cents and deterministic rounding.
• Design and test a greedy algorithm (fewest-transactions settlement) including its limitations.
• Build a first mobile app with local persistence and clear screen flow.
• Practice property-based testing for arithmetic invariants (balances always reconcile).

Why This Idea Is Different

The site’s mobile cluster already has a habit tracker with analytics and an offline-first note-taking app, and the finance cluster has a personal finance tracker for freelancers. None of them solve the group problem: this is not personal budgeting and not personal habit tracking — it is shared-expense settlement, where the interesting work is the group math (rounding, netting, and minimal payments). It is also deliberately the smallest-scope build in its batch: a beginner can ship the core algorithm in pure functions before touching the UI.

What Similar Tools Exist

| Tool type | Approach | Limitation |
|———–|———-|————|
| Commercial split apps | Full-featured social splitting | Accounts, sync, and features far beyond a beginner build; opaque math |
| Spreadsheets | Manual tracking and formulas | Error-prone, no settlement plan, no mobile UX |
| Payment-app splitting | Split at payment time | Tied to one payment network; no group history |
| Notes-app tracking | Write down who paid what | No netting, no rounding rules, no settlement plan |

This project’s differentiators: exact, documented rounding; a transparent settlement algorithm; local-first privacy; and a scope that lets a student own the entire codebase.

Technology Stack

• React Native or Flutter — mobile UI (choose one; the logic is platform-agnostic)
• Local storage — SQLite (or AsyncStorage) for offline-first persistence
• A pure computation module — balance engine + settlement algorithm, framework-independent and fully unit-tested
• Jest (or the framework’s test runner) — unit and property tests
• Optional later: a small Node/Python sync backend with real authentication

Future Enhancements

• Cloud sync with authentication and documented conflict handling
• Receipt uploads for auditability
• Currency conversion with explicit rates and disclaimers
• Recurring expenses (rent, subscriptions) with auto-suggest
• Export to CSV/PDF for group record-keeping
• Read-only share links for groups that don’t want the app

Related Ideas

• Mobile Habit Tracker with Streak Analytics — another beginner-friendly mobile build with a clear data model
• Offline-First Note-Taking App with Sync — the local-first architecture pattern this app shares
• Personal Finance Tracker Built for Freelancers — personal budgeting; this app is the group-sharing counterpart

Browse more Mobile ideas · Project Ideas