One Problem, Two Markets: Designing Expense Settlement
Link: Prototype link available below
Industry:
Fintech
The Client
Independent personal work, completed solo
The Problem
The difficulty in expense splitting is rarely calculation. It is the conditions under which repayment happens.
Environment | Dominant failure mode | Consequence |
|---|---|---|
Nigeria | Delayed or unclear payment confirmation | Disputes, follow-ups, social tension |
UK / Europe | Extra steps or ambiguous actions | Hesitation, drop-off, non-reuse |
Many expense-splitting tools implicitly assume:
reliable confirmation,
comfort with reminders,
and tolerance for follow-up outside the product.
Those assumptions do not hold consistently across markets.
A single universal solution would therefore:
fail in Nigeria by being too optimistic about reliability, and
fail in the UK/Europe by adding unnecessary interaction cost.
The Goal
Design two products that support the same behaviour — settling shared expenses — while accounting for different failure risks.
MoniSplit: reduce uncertainty and social friction when confirmation cannot be assumed.
myPay: reduce interaction and cognitive cost when reliability can be assumed.
Success was not defined as feature completeness or launch readiness, but as choosing a direction that would not collapse under realistic conditions.
Research & Foundations
I reviewed existing expense-splitting products such as Splitwise and Splity to understand how the problem space is commonly addressed.
Splitwise functions primarily as an expense ledger and reconciliation system. Its strengths include itemization, receipt storage, balance history, analytics, and settlement optimization across time.
Splity emphasizes quicker, lightweight bill splits, often for short-term or one-off use.
This review clarified an important distinction:
Most existing tools prioritize tracking and reconciliation over time, not the moment an obligation is settled.
MoniSplit and myPay intentionally focus on this narrower moment: closing a specific obligation, under different constraints.
Constraint-Driven Reasoning
Beyond competitive review, decisions were informed by:
established fintech interaction patterns (wallets, transfers, chat-based actions),
infrastructure characteristics (e.g. delayed confirmations, USSD reliance in Nigeria),
and common P2P failure points (unclear status, social discomfort, mid-flow abandonment).
AI was used as a supporting tool to simulate edge cases and challenge assumptions, not as a substitute for product reasoning.
———
MoniSplit (Nigeria)
The Nigerian context introduces uncertainty at multiple points in the settlement process:
payment confirmation may be delayed,
fallback channels such as USSD are commonly used,
shared expenses often involve uneven consumption,
and reminders can carry social cost.
A recurring tension emerges:
Users want clarity and fairness without personally enforcing it.
This positions the product not as a calculator, but as a neutral system that absorbs friction:
item-level splits to reduce ambiguity,
multiple payment paths to handle failure states,
proof uploads to resolve disputes,
system-generated reminders to remove personal pressure.
The design does not optimize for speed.
It optimizes for reliability and social safety.
———
myPay (UK / Europe)
In the UK/European context, payment infrastructure is generally reliable and widely trusted. As a result, the primary risk shifts from verification to interaction cost.
Flow analysis and category patterns indicate that:
chat is a familiar entry point, but unstructured messages are easy to overlook,
additional steps increase abandonment in competitive markets,
and repeated use depends on reducing effort rather than providing reassurance.
A key observation:
When a financial request behaves like a normal message, it competes with non-financial content and loses salience.
myPay addresses this by:
constraining the flow to a small number of intentional actions,
surfacing frequent contacts to support repeated behaviour,
and representing requests as distinct action objects, not plain text.
Here, the design goal is friction reduction.
Design Decisions
What was prioritised first:
Decision | Rationale | Product effect |
|---|---|---|
MoniSplit: proof uploads | Confirmation cannot be assumed | Reduces disputes |
MoniSplit: USSD fallback | Transfers may fail | Prevents dead-ends |
MoniSplit: system reminders | Personal follow-ups carry social cost | Keeps resolution in-app |
myPay: Top Friends | Repayment is often repeated with the same people | Reduces initiation cost |
myPay: structured request flow | Unstructured chat reduces clarity | Improves completion |
myPay: request as card | Financial actions require salience | Reduces hesitation |
Request as a card (myPay):
Payment Request Sent (MoniSplit):
What was intentionally excluded
No unverified “quick split” in MoniSplit.
No full chat system in myPay.
No secondary features without evidence of core flow viability.
These exclusions were deliberate, not omissions.
Core Flow (myPay)
Intent: allow a user to request a split from a frequent contact with minimal friction, without entering a generic chat.
Flow:
Bill split flow
The Home screen surfaces “Top Friends” to eliminate search and reduce initiation cost.
Tapping a friend bypasses generic chat and opens a structured split flow, preventing ambiguity.
The amount + message input happens in a guard-railed interface, not free text.
The request becomes a persistent card, not a message that can be lost in chat history.
The confirmation screen reinforces trust (“request sent”) without adding steps.
Core Flows (MoniSplit)
This flow assumes that payment confirmation may be delayed and that reminders carry social cost.
Instead of optimizing for speed, the design optimizes for clarity, recoverability, and emotional safety.
Each step exists to prevent a known failure mode: disputes, forgotten payments, or relationship strain.
Bill Splitting:
Payment Flow:
Key Takeaways
Expense splitting is constrained by environment, not just intent.
Trust and friction are not universal concerns; their relevance depends on infrastructure.
Products fail when they assume conditions that do not hold.
Early product work is often about defining what not to build.
This case study reflects how I approach product design under uncertainty: by identifying failure modes early and designing explicitly around them.
