CASE STUDY · ZERO-TO-ONE · 18 MIN READ

Bill Split

Shared experiences over shared expenses

Shaping YouTrip’s first ever group expense platform from a Day 1 MVP to frozen-FX settlement, custom splits, and a debt-optimization algorithm.

Shaping YouTrip’s first ever group expense platform from proof of concept to frozen FX settlement, custom splits, and Simplified Payments

Please view on desktop

BUILT FOR

YouTrip Singapore

ROLE

Solo Product Designer (and PM for a stretch!)

STATUS

v3 beta live since Jan 2026 · v4 shipping in Q3

+84%

avg YoY spend uplift & 2x FX spend for adopters vs. non-adopters

avg YoY spend uplift & 2x FX spend for Bill Split adopters

MoM ↑

consistent growth of v3 since beta launch despite being a relatively hidden feature

growth since beta launch despite being relatively hidden

versions · 3 usability tests · 1 constant (me 👋🏼)

TL;DR

What. Led design for a bill split product that grew in complexity across 4 versions

Beta is live today with one-off and custom splits, payment rails, frozen FX, and follow-up nudges
Shipping in Sep 2026: Groups + Simplified Payments (app within an app, positioned to replace competitors entirely)

How. Solo designer wearing multiple hats; had a month-long PM stint where I wrote the PRD, feature implementation plan, and decision records on top of finalizing all Figma screens for hand-off

Outcome. The beta release resulted in an +84% YoY spend uplift and 2x FX spend for beta adopters vs. +6% for non-adopters, all with zero homescreen entrypoints or marketing fanfare

Personal highlight. Bill Split rewired my reflexes to think like an FE and QA - after four versions of dealing with unexpected edge cases, I can now predict complex scenarios much quicker

This has translated into fewer handoff loops in all my projects, because we get it right the first time

01 / Context

YouTrip is a leading multi-currency travel wallet operating in Singapore, Thailand, and Australia. Our card enables travelers to spend overseas at the lowest FX rates without the usual gotchas.

Travel lies at our core, and knowing our user base, it’s rarely done solo! However (in Singapore at least), group expense management usually lives in five apps at once.

Nobody really owns the full loop
of split, settle, and stay.

Plan

WhatsApp + Notes

💳

Pay

Take turns fronting costs, accumulate photos & screenshots

Track

Manual entry on Splitwise or spreadsheets

Settle

Weeks-late FX conversion, transfer from app to app

Post-Trip

No way to reflect on spending, no reason to return to group

The common (fragmented) stack, mapped after chatting with several SG colleagues about traveling with friends

Our identified competitors each take a different stab at the problem: Splitwise and Tricount are ledgers with zero money movement, Wise and Revolut include bill split as more of a side quest with hard-to-find entrypoints and confusing UI.

YouTrip

Splitwise

Tricount

Wise

Revolut

Google Pay

PayPal *

Venmo †

Tracks splits

✓

partial

patchy

—

✓

Moves money

✓

—

✓

Lowest FX

✓ frozen historical

paywalled

—

Owns the full loop

✓

—

Based on in-depth competitor benchmarking conducted during the project
* Available in SG but with no bill split functionality · † US-only

On top of the app-switching sit the human problems: calculation complexity, the awkwardness of following up with friends, zero settlement transparency, and the hesitation to even get started.

+47%

spend, P2P active vs. non-P2P users

1 of 3

approved users not yet financially active

On average, P2P active users spend +47% more than non-P2P active users. Bill Split can create more P2P activity, and get more users into that high-spend group. And although this might just be directional evidence, the fact remains that every split settlement that happens outside YouTrip leaks our FX advantage to someone else’s rails.

To add, every split can act as a low-CAC growth loop: users who aren’t on YouTrip have a social reason to join, and dormant ones may be pulled socially to use their cards.

SOLO DESIGNER · YT SPLIT

02 / My role

ON PAPER

Research & ideation

incl.

UX & UI

incl.

Usability testing

incl.

Microcopy & content design

incl.

Design QA

incl.

IN PRACTICE, ALSO ↓

Competitive strategy

Edge-case governance

GTM support

1 critical month of PM work 🙏

Total hat count

👒 x9

03 / Phased strategy

Bill Split was built in four phases, each shaped by an existential question from management.

V1

MVP / proof of concept

REQUESTOR POV

V2

"HMW add payment rails?"

REPAYER POV

V3 · Jan 2026

“HMW handle unequal splits?"

BETA launch

V4 · Q3 2026

“HMW replace competitors entirely?"

Shipping soon

CNY ×2

Rate Updates

Campaigns

UX Content Audit

Home v2 + Bento

Auto Top Up

My team would often be building 2-3 other features in parallel, usually of similar size/scope (Campaigns, for example - case study in progress 🚧)

V1

The experiment

Scope:

Split any YouTrip transaction among YT and non-YT users (via text-only placeholders)
Follow up with shareable templated messages
Mark individuals as paid - but no in-app money movement

I was handed off the happy path mid-fis, then quickly learned just how much there was still to go. I had to design the flows for every transaction state that wasn’t perfect (pending, refunded, disputed, reversed), go through a Lokalise trial-by-fire, stress test long names and “splits without self”, and show what each split looked like from initial creation -> partially paid -> fully paid. (And all without a functioning B2C design system!)

Sometimes, the happy path is only 10% of the work. The actual product is the edge cases.

The state-space mastery and broad content design became the foundation for every version that followed. It was a real workhorse moment for someone new to the B2C team, especially since this was before AI joined the YouTrip tech stack.

INHERITED

What I was given…

ACTUAL COVERAGE

…and the full state space.
Even had to design for what happens when someone in an equal split has to pay slightly more!

Transaction type x participant type x SGD vs. non SGD x split progress x

Each scenario needed its own follow-up message + Lokalise keys

BEFORE

AFTER

P2P was due for a revisit (its Figma barely mirrored what was in prod!) We shipped the improved screens just in time for YouTrip's AU launch - a two birds, one stone type of deal 🐦‍🔥

V1 only had us designing for requestors. Now we had to design for repayors as well!

V2

Payment rails

Scope:

Money movement with FX
Multi-transaction splits
Requestor vs. repayer views

V2 required us to revisit YouTrip’s existing P2P Send, a core flow which had remained untouched for roughly two years. I shipped UX enhancements to P2P alongside mapping the requestor/repayer dual-POV flows.

Halfway through, my PM and I were pulled into a new zero-to-one project. Another PM/designer combo carried v2 forward. Alas, right before launch, management got cold feet and questioned if it was worth launching if users could only split transactions equally each time…

V3 · LIVE!

Custom splits & beta release

Scope:

Uneven splits (exact amount, percent, share) that accommodate multiple FX, multi-transaction handling, and tailor-fit follow-up messages
Dedicated split landing page
Split naming
Blocking & reporting bad actors

Fresh off launching Campaigns, I was brought in again to make Bill Split truly, finally “shippable”. It was a real challenge inheriting a lot of UI/UX calls from v2 that I didn’t necessarily agree with, however, many a 1:1 later, we made it through.

I wanted to work smarter after getting burnt out from all the v1 edge case firefighting. I planned a pre-grooming edge-case mapping session with FE/BE/QA that became a standing ritual for Bill Split. Prevention is better than the cure: these sessions helped us proactively design and address the hydra heads that kept popping up from each hyper-specific custom split scenario.

As the feature kept growing in complexity, I also conducted usability tests with 5 non-product employees to check that we were on the right track.

BE: What emoji do we use as fallback if a transaction's MCC cannot be mapped?

FE: Do inputted amounts carry over when the user switches split methods?

QA: Do we also convert what's in the fields when the user switches currencies?

5 employees x 4 split scenarios (1 for each split method)

WHERE I WAS WRONG & THEY WERE RIGHT

Payments Page. I advocated for a Wise/Revolut-style payments hub as the home for splits. After quickly mocking up a couple of layouts, I ran 5 guerrilla tests in the PH. Only 2/5 participants clicked on the Payments entrypoint when I asked them to create a split (however they always looked into Transaction History!) The VP of Product also worried the page signaled a product depth we didn’t have yet.

KILLED

SHIPPED 🚢

We killed the idea and shipped three humbler entrypoints for v3: 1) the transfer button, 2) transaction history, and 3) individual transaction bottom sheets (existing).

Transaction bundling. The v2 working team decided splits should have the ability to contain multiple transactions, which I didn’t necessarily agree with (I didn’t think it was worth the complexity it added). Then the beta data came in - I guess they made the right call!

73.30%

single-transaction splits

1 in 4

splits bundled transactions

V4 · SHIPS SEP 2026

Groups: from feature to platform

Scope:

Group creation and pages
Dynamic dashboard with aggregate CTAs to pay or follow up
“Add an expense” flow
Simplified Payments (debt-optimization algorithm)

As soon as we got the sign-off to launch Bill Split in beta, we knew we already had to think of what to release next. My PM and I had ideation syncs at the same time, every single day, to spitball ideas and conduct extended competitor benchmarking. We finally landed on the concept of Groups, initially descoped for being "too big" of a build. It now seemed the right time to launch it and solidify Bill Split’s potential as a long-term acquisition lever.

I jumped out of Figma and into Slides, helping author the overall pitch, which included design principles, detailed feature comparisons, and a long-term vision that won leadership’s buy-in. Then came the design work proper: crafting UX and copy that respected the social rules and etiquette of spending as a group.

FYI: Budgeting & tracking spend (how much to budget, no running total vs trip budget, what did the trip cost) are the top pain points across 3 segments in a recent TH customer survey

04 / Deep dives

DD1

Simplified Payments

I advocated for it, so I had to own it 🫡

As our main goal with v4 was to replace competitors entirely, I staunchly advocated for us to include what we ended up terming “Simplified Payments”, despite how much it would delay our launch. Debt optimization is a staple in every top split app: Splitwise has Simplify Debts, Revolut has Smart Settle, and Tricount does it automatically (which I wasn’t a fan of, and wanted to provide flexibility on!) I felt Groups would only be right if we had it as well, and got buy-in.

Up to

50-70% reduction

in group transfers needed

However this was a double-edged sword; I now had to own how it behaved. Given how Bill Split was designed from v1 to v3 in its own specific way, I couldn’t just copy competitors blindly. I treated our unique algorithm as a UX surface and wrote SP's behavioral rules:

Entry. Groups can’t turn SP on until every member has accepted their group invite. Enforcing a black-box triangulation for those who haven’t consented to be in the group could erode trust on day one.

Commitment. SP is freely toggleable until the first repayment; after that, it’s locked ON until everyone settles. Money has already moved under the optimized plan, so it must hold.

Liveness. New splits, deletes, declines, and marked payments all recalculate balances and suggested transfers in real time while it’s on.

Exit. SP auto-toggles OFF once all ongoing splits are fully settled, so users are never locked into a mode by mistake.

I had to make sure the math checked out in every single Figma screen to prevent any confusion from the devs, especially since this was such a backend-heavy feature and the Figma was being referenced by many. Initially I tried to program Claude to act as my Simplified Payments agent, but it would mess up the settlement math every other time. In the end I built an Excel sheet where I would plug in hypothetical SP scenarios, get accurate figures, then input them on Figma.

Product design can be Excel sheets too 🤭

DD2

Research & Validation

🇵🇭 5-person trial run · 🇸🇬 10 x 60-min sessions in 4 days

Each version of Bill Split except the first underwent guerrilla testing. v2’s killed the Payments Page (saving us immense, unnecessary dev time) and v3’s improved the vocabulary and micro-interactions of custom splits.

Come v4, Bill Split had slowly but surely grown into an app within an app. The engineering investment finally justified going big; I made the case for flying out to SG to conduct formal usability testing. It didn't hurt to ask, because I got the go-signal and a finance-approved incentive budget 🙏🏽

As the Groups experience involved even more parallel flows that would be too exhausting for a single participant to go through, I split the UXR into two sets, which would also provide cleaner results for both user POVs.

Set A · Creator

Create group

Create split with custom expense

Use Simplified Payments

Settle and leave

Set B · Joiner

Join/decline group

Find/select group

Pay using dynamic dashboard

Add members to existing group

Two POVs means two sets of prototypes and scripts 😮‍💨
I brought vegan chicharon + other snacks from the PH to thank each participant for their time!

THE ORIGINAL PLAN WAS TO VIBE-CODE…

…but after playing around with Magic Patterns & Figma Make for a day, I decided that the linearity of the UT flows didn’t justify the overhead. Instead, I went with the usual Figma prototypes which gave me more time to trial run the UT scripts with my PH officemates ✈️

Justified a spot on the homescreen

Participants ignored the nested v3 entrypoints when asked to create a group. This gave us ammo to vouch for Split's place as the 4th quick action button in home, which is huge!

Made the math clearer

Participants would puzzle over all the numbers in the Group page. Initially I thought it was because there were too many figures, but reversing the layout and tweaking the copy between UTs resolved things.

Improved SP comms

The UTs made us realize that it was better to overcommunicate SP rather than toggle it on silently. We subsequently doubled down on notifications and explanations.

DD3

Migrating mental models

Play it safe or go all in?

Every platform shift encounters a quiet migration problem: what happens to the user who learned the old design? My first v4 landing page tried to protect them (and our devs) through a backwards-compatible landing page, which tried to retain as much as possible from v3 to avoid reinventing the wheel and help us ship ASAP. But after seeing the final v4 designs, the founder wanted us to go all in on Groups. We iterated while I was still in SG and got sign-off before I flew back home.

V3 + INITIAL V4 PROPOSAL

Went back to the drawing board, literally

FINAL (GROUPS-MAXXING!)

However this layout further cemented the mental model shift from split-level tracking (v1-v3, i.e. Cosmo pays Bowie for Split A, then Split B, then Split C) to balance-level netting (v4: Cosmo pays Bowie for Splits A/B/C in one go). This meant that for Groups, we would have to do away with the v3 ability to decline individual splits, a concession the team was willing to make for Phase I.

We ended up with a compromise that honored what we had already built: users could create ad-hoc splits from the old pathways, but any splits made from the v4 entrypoints would automatically create groups. v3 power-users could still see past and ongoing ad-hoc splits, while users encountering Bill Split for the first time would just understand it as Groups (the goal).

Leveling up means building a bridge between the product that users know and the improvement that's replacing it. The PD challenge lies in ensuring that bridge supports weight from both ends!

Good design is compromise that doesn't feel like it.

DD4

PM LARPing

Filling a month-long product gap

Mid-Q1, my PM went on leave for military service. There was no one to sub for him, and the VP of Product had just resigned. Engineering was on an 8-week clock, but since the PM and I had ideated on Groups in Figma first, no PRD existed… while this is slowly becoming the norm, YouTrip devs and EMs still look to PRDs as the source of truth.

I volunteered to write the Bill Split v4 Groups PRD from scratch to guide the development workflow. Alongside the usual items (market context, vision/mission, objectives, success metrics), I hunkered down on the full requirements (C0–C14), the notifications matrix (Groups was adding further layers of etiquette to the app’s social rules), and the phased implementation Engineering needed to proceed. I organized every feature from the designs into three categories: P1 Essential / P2 Scaling Up / P3 Quality of Life, with P1 scoped explicitly to fit the founder’s 8-week budget. This became Engineering’s bible for v4.

GROUPS (V4) PHASING

FOUNDER’S 8-WEEK BUDGET

P1 · Essential E2E

Create group · Group page · Simplified Payments · Add an expense

P2 · Scaling Up

Global split search & dashboards · Increased P2P/transaction limits etc.

P3 · QOL

P1 ships this Sep 2026 · Several P2 and P3 designs are ready but have been descoped

Scoped to make the most out of our resources

NOTIFICATIONS MATRIX

EVENT/TRIGGER

SEND NOTIF TO…

CONTENT

SAMPLE

User creates group

Group creator

Group created

%1$s is now live! Happy splitting 👯

Group created

%1$s is now live! Happy splitting 👯

User adds member(s) to existing group

User(s) invited to group

You were added to a split group

%1$s is inviting you to join %2$s

You were added to a split group

%1$s is inviting you to join %2$s

User declines group invite

Group creator + affected members

Group invite declined

%1$s declined to join %2$s. They’ve been removed from any splits they were added to.

Group invite declined

%1$s declined to join %2$s. They’ve been removed from any splits they were added to.

User creates split in existing group

Split creator

Split created

“%1$s” was added to %2$s

Split created

“%1$s” was added to %2$s

User deletes split from existing group

All group members minus split creator

A split was deleted 🗑️

%1$s deleted the split “%2$s” from %3$s.

A split was deleted 🗑️

%1$s deleted the split “%2$s” from %3$s.

User transfers within group (P2P)

Sender / recipient

Successfully settled up ✅

You paid %1$s %2$s %3$s in %4$s

Successfully settled up ✅

You paid %1$s %2$s %3$s in %4$s

Consolidated ref - no need to dig through Figma every time

🔒 LOCKED

Users must create group if accessing from v4 entrypoint(s)

Only YouTrip users can be added to groups

"Add your own expense" to be inputted in SGD only for P1

Split-level tracking to no longer apply to v4

+ 9 more

🔖 OPEN

HMW treat group splits after they're deleted?

HMW handle group creation if users have only selected 1 contact? (Is it still a group?)

HMW communicate to users who have invited someone to a group and already involved them in splits that they have declined to join?

+ 6 more

Additional docs that helped onboard both senior & junior hires

The biggest point of contention I had with the PM before he went on leave was whether Groups should be open to non-YT users as well. We allowed this in v3, so why not do so for Groups? After investigating on MTB, I found that only ~5% of v3 split participants were non-YT users (5.05% Jan · 4.23% Feb). Rushing to build mixed-member flows just for PI meant extending our already-bloated sprint estimate on a sliver of an audience.

I wrote a section in the V4 PRD specifically arguing against including non-YT users in Groups, which got everyone on the same page:

THE DATA

Only ~5% of v3 split participants were non-YT users (5.05% Jan · 4.33% Feb)

THE CALL

YouTrip users only, for P1 at least!

RATIONALE

YT users won't need to act on behalf of others
Reduces SP complexity
Protects acquisition lever
Protects payment rail integrity (vs. making it useless)
Cuts down on MVP scope

CONS ACCEPTED, IN WRITING

Further mental model inconsistencies with v3 (allows placeholder members)
Chance of users defaulting to Splitwise instead of inviting friends to YouTrip

ELSE,

We retain non-YT user placeholder members in Groups P1 -> more edge cases to design and build

RE-EVALUATE AFTER P1 LAUNCH IF

Users drop off after learning they can't add placeholders in groups
Placeholder use in ad-hoc splits increases
Outside settlements don't decrease

05 / Shipping quality & the last mile

My laundry list also included cross-market and cross-team deliverables that would ensure the feature could launch in AU 🇦🇺 / TH 🇹🇭 / HK 🇭🇰 at a moment’s notice.

ACCESSIBILITY

While SG is a bit more lax with WCAG recs, the AU government isn’t. I pushed for us to already employ bigger fonts, darker colors, and more accessible spacing to enable a plug-and-play setup for the Bill Split AU launch.

We also started pushing for sentence case in all titles and buttons, as part of an AU/SG UX Content Audit I was spearheading.

DESIGN SYSTEM

Bill Split heavily used transaction components which often had to be detached because they didn't match what was in prod. I volunteered to give all transaction-related components in our DS Asset Library a complete facelift, reorganizing them to help other team projects as well.

After almost 2 years of design & dev, the Figma file was getting bloated too. I migrated everything into a new file to make it easier for new devs/QAs to understand.

GTM x MKT

As part of the v3 and upcoming v4 launches, I helped the CS/Ops team draft their Bill Split FAQ guides, and brainstormed with MKT on the final USPs for Groups.

06 / Beta launch & results

The v3 launch in January was a deliberately quiet one: no homescreen entrypoint and no full-fledged marketing campaign. We still saw increased spend for Bill Split adopters, with consistent MoM growth and retention.

IMPACT

+84% avg YoY spend*

uplift for Bill Split adopters vs. +6% for non-adopter users

+102%

+13%

Jan

+66%

+5%

Feb

+82%

+1%

Mar

*Based on Q1 of public beta, the cleanest cohort before adopter base tripled in Q2

GROWTH

64,948 splits

created from Q1 to Q2 , with monthly volume tripling in five months

4.8k

14.7k

Q1 2026

Q2 2026

RETENTION

56% came back

to create another split, and repeat users grew every single month

119

4,073

Q1 2026

Q2 2026

While we were quite pleased with these results (especially the 2× FX spend difference between adopters and non-adopters!), it’s worth noting that 48.6% of roughly 160k Bill Split repayments were still settled outside of YouTrip (v3 has a “Mark as paid” feature that lets users record when they’ve received payment elsewhere.) Half of the split loop still leaks off our rails, but this is exactly what v4 (Groups, Simplified Payments, dynamic dashboard) is meant to address.

Other fun facts about v3:

Average splits sit around ~84–104 SGD, with the top split currencies in order being JPY, MYR, CNY, and KRW
Splits on average have 2.52 participants (hopefully Groups can change this!)
1 in 4 splits uses a custom split - shipping the v3 build was a good call

DO NOTE

Bill Split adopters may also be spending a lot because they’re power users (correlation, not causation 🙏🏽). But the gap did widen across Q1 with non-adopter uplift fading to nearly zero by March while adopters held above +80%!

07 / Reflections

Aside from that blip in v2, I was Bill Split’s one true constant through its four evolutions. Here are some takeaways from almost 2 years of constantly increasing ownership:

THE HIDDEN STATE SPACe: how BILL SPLIT GOT COMPLEX

4
txn states

completed · pending · disputed · reversed

4
split methods

equal · exact amount · percent · share

3
currency types

SGD · wallet ccy · non-wallet ccy

4
split states

ongoing · completed · deleted · declined

2
user POVs

requestor vs.
repayor

+SP

2
mental models

ad hoc vs.
group

700+
states

several major combos designed, copywritten & QA’d

On live payment rails + FX engine…

…and debt-optimization algo!

Pixel density is not a proxy for difficulty. Mobile app work looks (deceivingly) simpler than web dashboards… but it isn’t. A B2B dashboard wears its complexity on the surface: dense tables, filters, admin roles. A consumer split flow hides its complexity in the state space: transaction states × split methods × currencies × participant states, sitting on live payment rails and an FX engine, wrapped in state-specific copy that always has to make the debt feel casual and friendly. Which is why I’ve learned to…

Design the full state space from day one. v1’s ad-hoc pain became v3’s edge-case mapping ritual became v4 wireframes that already spotted edge cases before the QA did. Bill Split taught me to think like an FE and a QA before the first handoff, cutting down on back-and-forth during development. I do believe this reflex has led to helping the team ship faster and faster each time.

When the org has gaps, volunteer to fill them. PRDs, decision records, and phasing strategies aren’t always seen as the PD’s work, but they’re very much design deliverables too. Contributing to the strategic framing and tradeoff handling that got management sign-off and gave Engineering a proper head start turned out to be the most rewarding part of this project for me.

So what's next? v4 Groups Phase I ships this Q3 2026. P2 (landing page dynamic dashboard which aggregates across all splits and groups, edit functionalities, etc.) will be fast-follows post-launch. And P3, the “After” phase of splitting that ultimately closes the loop on shared experiences over shared expenses, is patiently waiting for its turn to be scoped.