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.
We 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
The core problem isn't tracking money. It's that there's no system designed around the social dynamic — so people default to group chats, which puts 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 solve the awkwardness problem partially, but neither eliminates it. Someone still has to front the money. Someone still has to chase.
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 two or three of those steps are genuinely annoying: 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.
That last part was the hardest to design around. We couldn't eliminate the step — the leader has to physically go subscribe using the virtual card. But we could make it feel less like falling off a cliff.
testing & Iterating
how do we build trust?
However, creating a virtual card from Stripe, a third-party platform, poses many challenges that we didn't foresee:
Many steps for the leader
To create a virtual card, users are required to submit personal details and link a bank card. For a brand-new app, this step introduces a high risk of drop-off, as many users fear their financial information could be compromised. Building trust here is critical: the process needs clear communication, visible security assurances, and transparency about third-party providers.
Another friction point lies in the cost itself. While generating a virtual card only incurs a fee of 10 cents, 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.
Finally, the group leader faces the most complex burden. Their responsibilities extend beyond personal setup: they must select the subscription, invite or approve members, finalize the group, split the cost, send out payment consent, wait for approvals, create and fund the virtual card, and only then use it to purchase the service. This long, multi-step process is where abandonment risk is highest. Simplifying and clarifying the subscription flow for leaders became a key design priority to keep groups from stalling before they even begin.
Leader flow – Creating a subscription sharing group
The steps of work required for the leader to subscribe to a shared service.
The proposed solution
Building trust through communication & allowing autonomy
For the User Information and Card Details modals during onboarding, I added a tooltip for extra information, while also making these screens optional so the user can skip, allowing the app to build trust for the user before prompting them to commit to our MVP. Without a virtual card, users can still manage their personal subscription.
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, I broke down the service-subscription part into steps for the leader, providing them with context on navigating outside of the app, subscribing, and coming back to activate the subscription for the group members.
the Final product
fairshare.