PossePay
The group tip math where "some extra money" never seems to be enough. We've all been there. PossePay was a Bulgarian fintech startup letting people scan, split, and pay their restaurant bill individually - no app, no friction. I joined as co-founder and sole product designer.
Validating the problem
Before designing anything, we needed to know whether the bill saga was a genuine pain point or just something people complained about and then forgot. So we asked. We surveyed over 100 people about their most recent dining experience, looking for behavioral patterns and recurring frustrations. The data confirmed what we suspected - splitting the bill and tipping by card were consistently painful, and existing workarounds felt clunky.
Two charts aggregating average team data dominated the interface - almost nobody could interpret them. The layout felt unintuitive, and the information on offer gave users little they could act on.
What we decided to build
Scan, split, and settle the bill with only a few clicks. We made an early call to go web rather than native app - we didn't want to ask users to download anything before they'd even tried the product. We partnered with Enbank, a Bulgarian fintech startup, to handle payments and keep processing fees lower than traditional POS terminals. Based on our research, we prioritized three things for V1: - Reviewing the bill in real time - Splitting it by selecting individual items - Tipping by card - something still rare in Bulgaria at the time We leaned hard into the tipping feature specifically, knowing that waitstaff recommending the product to guests would be one of our strongest growth levers.
What the interviews revealed
The picture was consistent: the tool was trying to do too much, and wasn't doing anything particularly well. Developers felt it wasn't speaking to them - the experience was built for everyone, which meant it worked for no one.
Shifting toward a personalised experience
Rather than surfacing everyone's scores, I focused the interface on the individual — their parameters, their score, their coaching output.
Learning from real use - again
I spent three sessions at the bar talking to users directly and watching them interact with the product. Three issues came up consistently enough to act on.
The bill breakdown layout
People were tapping items in the breakdown list to select them, not realising the checkboxes were hidden below the fold. I iterated with two concepts that surface the selectable items earlier.
Status clarity
We showed payment progress in two places but didn't make the relationship between them obvious. People lost track of where they stood. I redesigned the status display to make it unambiguous at a glance.
The payment slider
Slide-to-pay was meant to prevent accidental confirmations - but it was unfamiliar enough to slow people down. I replaced it with a more conventional confirmation pattern.
How it ended - and what I'd carry forward
After four months live, we stopped.
Difficulty onboarding new venues, payment processor limitations, and some critical transaction errors made it clear we couldn't scale. It wasn't the ending we hoped for - but it taught me that real-world feedback beats upfront assumptions, and that cutting features is often better design than adding them.