PATE - AI Bill Splitting App
Designed in Figma in 2024, then built and shipped as a live product. A bill splitter where nobody types a number.
· Project Goal: Build a bill splitter that removes the maths from the end of a group meal entirely, and take it all the way to a live product people pay for. · My Role: Product Designer, then everything after. UX research, front and back end direction, QA, security review, compliance and support. · Impact: A live application at patesplit.com reading receipts in three regional tax formats, with subscriptions, install flows and admin tooling. Designed by one person and built without engineers.
· Project Goal: Build a bill splitter that removes the maths from the end of a group meal entirely, and take it all the way to a live product people pay for. · My Role: Product Designer, then everything after. UX research, front and back end direction, QA, security review, compliance and support. · Impact: A live application at patesplit.com reading receipts in three regional tax formats, with subscriptions, install flows and admin tooling. Designed by one person and built without engineers.
Company
Own product
My Role
Product Designer, UX Research, AI-Assisted Build Direction
Product Designer, UX Research, AI-Assisted Build Direction
Industry
Restaurants & Payments
Date
March 2024 - August 2026
Every portfolio piece has a tidy origin story. This one is honest: I designed PATE fully before I had any way to build it, and then spent over a year finding out how much a Figma file leaves out. What the design phase could not tell me was which decisions would actually matter. On the screen, splitting a bill is a clean interaction. In use, it turns out to be a question of trust, of what happens when the input is wrong, and of who at the table can be bothered. Those became the real design problems, and none of them were visible until something ran. The sections below trace that gap, from the idea to a product people pay for.
Every portfolio piece has a tidy origin story. This one is honest: I designed PATE fully before I had any way to build it, and then spent over a year finding out how much a Figma file leaves out. What the design phase could not tell me was which decisions would actually matter. On the screen, splitting a bill is a clean interaction. In use, it turns out to be a question of trust, of what happens when the input is wrong, and of who at the table can be bothered. Those became the real design problems, and none of them were visible until something ran. The sections below trace that gap, from the idea to a product people pay for.
Every portfolio piece has a tidy origin story. This one is honest: I designed PATE fully before I had any way to build it, and then spent over a year finding out how much a Figma file leaves out. What the design phase could not tell me was which decisions would actually matter. On the screen, splitting a bill is a clean interaction. In use, it turns out to be a question of trust, of what happens when the input is wrong, and of who at the table can be bothered. Those became the real design problems, and none of them were visible until something ran. The sections below trace that gap, from the idea to a product people pay for.
I built the whole thing myself, directing AI tools rather than writing code. That matters less as a technical fact than as a design one: it meant I never handed the work off, so every compromise and edge case stayed my problem to solve rather than someone else's to interpret. The decisions that follow are the ones I am most willing to defend. Each came from watching the product meet reality, a receipt it could not read cleanly, a person who would not install anything, a flaw I found by attacking my own design. They are small individually. Together they are the difference between something that demos well and something that holds up. This is the part of the process that no prototype reaches, and the part I think says the most about how I work.
I built the whole thing myself, directing AI tools rather than writing code. That matters less as a technical fact than as a design one: it meant I never handed the work off, so every compromise and edge case stayed my problem to solve rather than someone else's to interpret. The decisions that follow are the ones I am most willing to defend. Each came from watching the product meet reality, a receipt it could not read cleanly, a person who would not install anything, a flaw I found by attacking my own design. They are small individually. Together they are the difference between something that demos well and something that holds up. This is the part of the process that no prototype reaches, and the part I think says the most about how I work.
I built the whole thing myself, directing AI tools rather than writing code. That matters less as a technical fact than as a design one: it meant I never handed the work off, so every compromise and edge case stayed my problem to solve rather than someone else's to interpret. The decisions that follow are the ones I am most willing to defend. Each came from watching the product meet reality, a receipt it could not read cleanly, a person who would not install anything, a flaw I found by attacking my own design. They are small individually. Together they are the difference between something that demos well and something that holds up. This is the part of the process that no prototype reaches, and the part I think says the most about how I work.
The thing I did not expect was how much of shipping is judgement rather than craft. Deciding a bill that cannot be cleared is broken regardless of what the code thinks. Deciding what someone's allowance should do when they cancel. Deciding not to launch on a day the numbers told me would go badly, and trusting the instruments I had built to tell me so. None of that appeared in the original design, and all of it shaped the product more than the screens did. That is the real argument of this piece. The interface was the easy part. Knowing which problems were worth solving, long after the file was closed, was the work.
The thing I did not expect was how much of shipping is judgement rather than craft. Deciding a bill that cannot be cleared is broken regardless of what the code thinks. Deciding what someone's allowance should do when they cancel. Deciding not to launch on a day the numbers told me would go badly, and trusting the instruments I had built to tell me so. None of that appeared in the original design, and all of it shaped the product more than the screens did. That is the real argument of this piece. The interface was the easy part. Knowing which problems were worth solving, long after the file was closed, was the work.
The thing I did not expect was how much of shipping is judgement rather than craft. Deciding a bill that cannot be cleared is broken regardless of what the code thinks. Deciding what someone's allowance should do when they cancel. Deciding not to launch on a day the numbers told me would go badly, and trusting the instruments I had built to tell me so. None of that appeared in the original design, and all of it shaped the product more than the screens did. That is the real argument of this piece. The interface was the easy part. Knowing which problems were worth solving, long after the file was closed, was the work.
Get in touch today to discuss how I can help you unlock your products 2.0! Let’s get on a call and make it happen with intuitive and impactful design solutions.
Get in touch today to discuss how I can help you unlock your products 2.0! Let’s get on a call and make it happen with intuitive and impactful design solutions.
Get in touch today to discuss how I can help you unlock your products 2.0! Let’s get on a call and make it happen with intuitive and impactful design solutions.