How would you improve Split Wise for Indian market?

First, I’d clarify whether we’re trying to make expense entry easier, improve settlement, or increase retention. These are connected, but they could lead to different solutions.

My understanding is that Splitwise helps people track shared expenses and understand who owes whom. I’d focus on making that shared record easier to keep accurate, especially when repayments happen outside the app.

1. Clarify the scope and objective

Before proceeding, I’d ask:

• What is the primary objective: accuracy, settlement completion, or repeat usage?

• Which expenses and payment methods are most common among the users we’re targeting?

• Are there regional or language needs to consider?

• Which existing features do users value and want to preserve?

• What are the timeline, budget, privacy, and security constraints?

For this case, I’ll assume we want to improve confidence in shared balances and make settlement easier within the next few months.

I’d preserve the simplicity of adding an expense and seeing the balance. I’d also avoid assuming that all Indian users have the same payment habits or comfort discussing money.

2. Choose a user segment

I’d consider four groups:

These groups overlap, so I’d use the expense-sharing context as the main distinction. Life stage, occupation, language, and accessibility needs would add useful detail.

I’d focus on a young professional living in a shared apartment who has used Splitwise for at least a month.

This person already understands basic expense entry and has recurring reasons to use the product. That makes it easier to investigate problems with maintaining balances over time, rather than mixing them with first-time onboarding difficulties.

3. Understand the journey and pain points

I’d map the journey as:

Pay for a shared expense → Record it → Allocate everyone’s share → Review balances → Repay → Update the shared record

For this user, I see four potential problems:

• Unequal contributions: People consume different amounts or agree to different shares.

• Repayments outside the app: Someone pays in cash or through another app, but the shared balance is not updated correctly.

• Uncomfortable follow-ups: Roommates hesitate to remind each other about outstanding amounts.

• Payment friction: Switching between the expense record and a payment app creates opportunities for mistakes.

I’d distinguish the expense split from the repayment method. If someone owes ₹1,500 and repays ₹500 in cash, their remaining balance is ₹1,000. The cash payment changes what remains owed; it doesn’t change their original share of the expense.

Before proposing additions, I’d audit existing settlement, unequal-split, reminder, and payment capabilities. The opportunity may be making these easier to understand rather than introducing entirely new features.

4. Prioritise the needs

I’d use basic needs, satisfiers, and delighters as a starting point:

I’d prioritise recording and understanding repayments made outside Splitwise, including partial repayments.

My hypothesis is that this is where the app’s record can drift away from what roommates believe happened. I’d validate that through interviews and observed settlement tasks.

5. Explore solutions

I’d consider four improvements.

Clearer repayment recording

Provide a straightforward “Record a repayment” flow with the payer, recipient, amount, date, and an optional method such as cash or external digital payment.

The screen would show the balance before and after the entry. It should clearly explain that recording a repayment does not transfer money.

More understandable flexible splits

Make unequal amounts, percentages, or weighted shares easier to select and review. Keep equal splitting as the simple default, with a clear preview showing what each person owes.

Customisable gentle reminders

Let users choose reminder frequency and wording, with options to snooze or stop reminders. A neutral message could point to the recorded balance without making assumptions about why someone hasn’t paid.

Local payment integration or handoff

Explore a connection to supported payment apps, such as UPI-based options, where available and feasible. I’d distinguish opening another app from receiving reliable confirmation that the payment succeeded.

An initiated or cancelled payment must not be recorded as a completed settlement.

6. Prioritise the solutions

I’d use RICE: Reach × Impact × Confidence ÷ Effort.

For illustration, these are hypothetical estimates for a pilot. Reach represents eligible users per quarter, confidence is a percentage, and effort is measured in person-months.

I’d replace these assumptions with research and engineering estimates before committing.

For the first release, I’d choose clearer repayment recording, with particular attention to partial payments and transaction history. It addresses balance accuracy and has fewer external dependencies than payment integration.

For example, after recording a ₹500 cash repayment against ₹1,500 owed, both people should be able to understand why ₹1,000 remains and see the entry that changed it.

7. Evaluate the trade-offs

Adding fields could make a simple action feel complicated. I’d keep the essential inputs prominent and make details such as payment method or a note optional.

A recorded cash repayment also isn’t independently verified proof that cash changed hands. I’d make entries visible to the relevant people and provide a clear correction history, with a way to flag disagreements.

Flexible splits offer control but can overwhelm users. I’d reveal advanced options only when needed and check that the allocations add up correctly.

Reminders could damage relationships if they become repetitive or insensitive. Users should control them, and reminders should stop when the recorded balance is settled.

Payment integration brings maintenance and trust requirements. I’d avoid duplicate settlement entries when users both record a payment manually and receive a payment confirmation.

8. Measure success and make the recommendation

My primary outcome would be settlement-record accuracy: how often the app’s remaining balance matches the participants’ agreed real-world balance.

Because we can’t automatically observe cash changing hands, I’d measure this through sampled user reconciliation and controlled usability tasks. Correction and dispute rates would provide supporting signals, but low correction rates alone wouldn’t prove accuracy.

Supporting metrics would include:

• Time and completion rate for recording a repayment.

• Adoption of partial-payment recording and unequal splits.

• User satisfaction with balance clarity.

• Payment completion rate, if an integration is introduced.

• Retention among recurring expense-sharing groups.

Guardrails would include duplicate entries, incorrect balances, feature abandonment, complexity-related support requests, reminder complaints, and security concerns.

I’d recommend improving repayment clarity first, then expanding into payment convenience. The goal is for roommates to look at the balance and understand what they owe, what they’ve already paid, and why.