02
FairShare
Project Overview
FairShare is a subscription-sharing app where groups split and manage services automatically: members link their payment once, and the app handles splitting, charging, and renewals through a Stripe virtual card tied to each shared subscription. I was the founding product designer on a team of four engineers, owning the project end-to-end from research to final prototype.
Role
Founding Product Designer
Team
4 Developers
Skills
UX Research
Information Architecture
Interaction Design
UI/UX Design
Timeline
March - July 2025
(4 months)
OKay so…
why do we still split netflix in a groupchat?
We all share subscriptions – Netflix, Spotify, YouTube Premium, you name it – but splitting costs is often messy. Most people rely on group chats and reminders. It’s clunky, confusing, and often unfair.
Who pays?
Who collects?
How do you trust everyone?
The problem
It isn’t just about tracking money. It’s the social awkwardness.
A friend of mine sent this message in July. It was a reminder to pay back everything we owed her for shared subscriptions from a school year that had ended two months earlier. Weeks of follow-up, private nudges, and a few people who just never paid.
I carried out 5 in-depth user interviews with people actively splitting subscriptions and uncovered that the core issue isn’t just tracking money, but the social awkwardness that comes with it.
Subscription holders
Hates chasing after
people to pay
Subscription members
Forgetful & annoyed
with being nagged
Privacy feels risky
There's no system designed around the social dynamic of tracking money, so people default to group chats, which puts at least one person in an uncomfortable position every single month.
ideation
What if the money splits itself?
Two directions kept coming up: a Splitwise-style reminder system (with manual splits and automated nudges) and a model where one person pays and the app handles reimbursement. Both partially solves the awkwardness problem, but someone still has to front their money, and worse, chase others for it.
The direction we committed to: what if no one has to front anything?
We initially explored Plaid for payment infrastructure, but ran into technical limitations that pushed us toward Stripe. That decision turned out to matter a lot: because Stripe's virtual card requirements introduced a chain of UX problems we hadn't anticipated, solving them became the core design work of the project.
Stripe said what now?
navigating trust, entry barriers, and complicated workflows
The team had committed to the concept of virtual cards early, and we were confident it was the right technical approach. What we didn't anticipate was how many UX problems Stripe's requirements would surface, one after another.
🚩 Problem 1
The trust barrier
To create a virtual card, users have to submit legal personal information and link a bank account on a brand new app they've never used before. In testing the concept with friends, the immediate reaction was: why does a subscription app need my legal name and bank details?
Building trust here is critical: the process needs clear communication, visible security assurances, and transparency about third-party providers.
🚩 Problem 2
The 10 cent fee
Stripe charges 10 cents to issue a virtual card. This price is objectively small, however this seemingly small amount can feel like a significant hurdle, especially for first-time users, who are unsure about the app’s long-term value.
🚩 Problem 3
The leader's workload
The member flow is 3 - 4 steps.
The leader flow is 4 - 6 steps, and 2 or 3 of those steps are a hassle to deal with (and in return, design for): linking payment info, setting up the virtual card, then leaving the app entirely to subscribe to the service and coming back to activate it for the group.
If we couldn't eliminate the work entirely, we could try make it feel less like falling off a cliff.
Leader flow – Creating a subscription sharing group
The steps of work required for the leader to subscribe to a shared service.
Design decisions
designing around what we couldn't control
⛳ Decision 1
Make the scary stuff skippable
The trust barrier was the hardest to solve because we couldn't remove the ask: Stripe genuinely requires legal name, date of birth, and billing address to issue a virtual card. So instead of front-loading it, I made both the User Information and Link Payment screens skippable during onboarding, with a tooltip explaining exactly why we need the information and what it's used for.
The deferred ask follows a simple rule: the app only prompts for the missing information at the moment it's actually needed, either when a user joins a group (payment method required) or creates one (full virtual card info required). By then, they've seen enough of the product to make an informed decision about whether to trust it.
⛳ Decision 2
Give the leader a map, not a cliff
The hardest step in the entire leader flow is one we couldn't design away: at some point, the leader has to leave the app, go subscribe to the actual service using the virtual card, and come back.
Instead of dropping leaders off with just a card number, I broke the out-of-app step into a guided sequence: copy the card details, open the service, paste into the payment fields, return and confirm. The "How does it work?" link surfaces the instructions inline so leaders don't have to figure it out alone.
⛳ Decision 3
No surprises before a charge
Prior to creating a virtual card, I also added a screen noting important information and use a checkbox both for background API requirements and making sure that the user fully understands the nature of using virtual cards for their subscriptions.
For group subscriptions, before any member gets charged, they see a consent screen showing their exact share amount, who set it, and a reminder that they won't be charged until everyone confirms. They can also expand to see all members' shares.
This one was partly a Stripe API requirement where consent had to be explicit, but it also directly addressed the trust and privacy concerns that came up in interviews. Making the charge visible and confirmable before it happens turns a potential anxiety point into a feature.
the Final product
fairshare!
The onboarding gets out of the way fast. Personal info and billing details are optional, and users can skip both and still access the app.
The group dashboard gives the leader a live view of who's confirmed, who's pending, and what the estimated split looks like before any money moves.
The leader controls the split. Equal split is the default, but the leader can assign custom amounts per member. The running total keeps the math transparent so that no one gets charged more than the subscription costs.
For the hand-off moment, instead of leaving leaders to figure out what to do with a card number, this screen guides them through copying details, going to the service, and coming back to confirm. The out-of-app step is unavoidable, but it doesn't have to feel like falling off a cliff.
Members see their exact amount before anything is charged.
Once the cycle starts, members can see their share, next payment date, plan details, and account credentials – all in one place.
Reflection
What i'd do differently…
FairShare taught me that most of the time, design constraints don't arrive all at once. They surface as you build.
Committing to virtual cards early set the terms for nearly every decision that followed: how we handled trust in onboarding, how much we asked of the leader, how we communicated charges to members.
Understanding that one technical choice could cascade that far changed how I think about early-stage product decisions, as well as the gap between what is ideal and what could be done, and designing to close that gap.
A few things I'd still want to explore:
and wrapping it up...
Still proud of this one!
This was the first project where I felt like a real product designer, although not everything went right. In fact, almost every of our initial idea gets pushed back under constraints. However, it taught me to make real calls under those constraints. I'm proud of what the team built, and even prouder of how much I learned from what we didn't get to.