Industry: Fintech / Concept
Time: Ongoing
Project Type: iOS
Completion: Prototype 2026
Built in Cursor with Swift
Split payment apps solve the math. None of them solve the actual reason group debt goes unpaid: asking for money back feels like begging. PartyPay started as a question about what fintech looks like when the design problem isn't the transaction, it's the relationship around it.
TL;DR
The decision that defined the product: the app does the collecting, not the person who paid. When someone covers a group expense, PartyPay sends the reminders, not them. The pings come from PartyPay, never from the person who's owed money, because the moment a reminder feels personal, the whole point of the feature collapses.
Three other calls: choosing IOU requires setting a pay-by date and explicit consent to auto-draft if it's missed, so the system can enforce a resolution without ever surprising anyone. Payment status stays private between the payer and each individual, the group never sees who's paid and who hasn't. The pot launches directly into the existing group text thread instead of a separate app screen, because that's where the conversation about the bill is already happening.
Biggest open question: whether removing the human ask actually holds up socially, or whether people read an automated reminder as colder than a friend asking directly. That assumption is the entire thesis of the feature.
Design decisions developed through systems thinking and Claude. Each one mapped, pressure tested, and defended against the actual failure mode it was meant to solve.
When it all made sense
Before designing a single screen, I mapped the actual loop behind the problem instead of starting from the interface. Unresolved debt makes asking feel more awkward over time. Growing awkwardness lowers the likelihood the person ever asks. The longer it takes to ask, the more time accumulates. That accumulated time breeds resentment, which lowers willingness to front money for the group again, which is exactly what keeps the original debt unresolved in the first place.
System map
The loop closes on itself, and counting the negative relationships in the cycle confirmed it's reinforcing, not self correcting. The longer it runs, the worse it gets. A one time reminder or a single payment doesn't fix a loop like that. The loop itself has to be interrupted. That single finding is what separates PartyPay from every other split payment tool. It isn't trying to make asking easier, it's trying to remove the ask entirely.
Why the pot starts in the group chat
The person who paid creates a pot and it launches directly into the group's existing text thread, the same pattern other payment apps already use to meet people where they are.
The challenge I had to answer: doesn't putting a financial action inside a chat thread undermine the seriousness of the transaction?
It's a fair concern, but it misses where the actual social moment happens. The conversation about the bill is already happening in that thread or even at the table before the pot ever exists, someone says "I got it," someone else says "let me Venmo you." Forcing that into a separate app screen doesn't add seriousness, it adds a context switch the user didn't ask for. The pot card is visually distinct from the surrounding messages specifically so it reads as a financial object, not a casual bubble, while still living where the conversation already is.
User flow
The other calls
The IOU as a commitment, not an excuse. Choosing IOU isn't a free pass to defer indefinitely. The user sets a pay by date and is shown, before confirming, that the app will auto draft the amount if it isn't paid by then, with one extension available. The consent happens at the moment of commitment, not sprung on the person at the moment of collection. This was the highest risk decision in the whole system. If the IOU has no real terms, the loop never actually breaks.
Visibility split by role. The person who paid sees the full breakdown, who's paid, who's IOU'd, by name. Everyone else sees only their own status, plus the group's names with no payment information attached. This is what keeps the structural pressure from turning into public shaming, the exact failure mode the feature is preventing.
A receipt that closes the loop in the same thread. When a pot is fully resolved, a closing card posts back into the same conversation where it started. No separate notification, no dead end, just a clean, visible close to the thing the group already saw open.
Wireframes
Final screens
What I'd validate next
Whether an automated reminder actually reads as neutral the way the system is designed to, or whether people perceive the absence of a human voice as colder than the awkwardness it's replacing. This is the assumption the entire product rests on, and it's not something a prototype alone can answer.
Whether the pay-by-date and one-extension structure on IOUs is generous enough for real friend groups, or whether it needs to flex based on the size of the debt. A $12 IOU and a $140 IOU probably don't deserve the same default terms.
Whether surfacing the pot inside an existing thread creates any confusion with the platform's own native payment features, and how that's disambiguated visually before this could ever be a real integration.
Changelog
2026 — Prototype
Built as a working SwiftUI prototype covering the full loop: pot creation, in-thread launch, the pay-or-IOU decision with the IOU consent flow, role-based status visibility, escalating reminders, IOU resolution including auto-draft, and the in-thread closing receipt.