DEVELOPMENT AND DESIGN
UX/UI design and front-end development. Final project of the Fictizia JavaScript course.
Designed in Figma. Built with vanilla JavaScript, HTML, CSS and Bootstrap.
Splitting expenses among friends or family always ends in manual calculations, confusion and forgotten debts. Party Budget automates that process and generates a clear summary of who owes whom and how much.
Party Budget was the final project of the Fictizia JavaScript course. The need was real, family Christmas gatherings always ended with the same conversation: who had paid what, how much each person owed and how to settle accounts without anyone feeling shortchanged. The app allows adding attendees, recording each person's expenses and automatically generates a final summary with the minimum transfers needed to settle all debts.
No formal process, design went straight to the result. The value of this project is not in the process but in the logic: calculating the minimum transfers needed to settle debts among multiple people is an algorithmic problem with more complexity than it appears.
Anyone who has organised a dinner, trip or celebration with friends or family knows the problem. No technical or financial knowledge required, the app has to be simple enough for anyone to use it on the spot, phone in hand, while still at the table.
Two flows could not fail: adding attendees and expenses quickly without friction, and generating a final summary that anyone could understand at a glance, with no ambiguity about who owes whom and exactly how much.
There was no formal exploration. Design went straight to the result. If I were to do it again today, I would start with wireframes of the two critical flows before writing any line of code, especially for the final summary screen, where debt readability is the only goal.
The most important decision was not visual but logical: calculating the minimum transfers needed to settle all debts, not simply dividing the total by the number of people.
Dividing the total by the number of people is the obvious but incorrect solution, it doesn't account for the fact that each person has paid different amounts to different people. Party Budget's logic calculates the minimum transfers needed for all debts to be settled with the fewest possible movements. That logic decision is what makes the app useful, without it, the final summary would be as confusing as doing the calculations by hand.
The app is used at a very specific moment, at the end of a meal or celebration, phone in hand and probably in a hurry. That conditioned all interface decisions: short forms, clear actions, no unnecessary steps. Bootstrap allowed building a functional and responsive interface quickly, prioritising utility over visual originality.
The main technical challenge was the minimum transfer calculation logic in vanilla JavaScript, no frameworks, no state libraries. All the logic weight fell on pure JavaScript functions.
No formal component architecture, the project was built with vanilla JavaScript, HTML and CSS with Bootstrap. The calculation logic was separated from the DOM in independent pure functions, which allowed testing the debt split logic without depending on the interface. That separation, though basic, was the most important technical decision in the project.
The minimum transfer logic turned out to be more complex to implement than it appeared on paper. The simple case, three people, equal expenses, was trivial. Real cases, five people, very different expenses, some having paid nothing, required an algorithm that sorted debts and settled them optimally. That complexity was not visible in the design and only appeared when writing the code.
A functional app that solves a real problem with non-trivial logic. The oldest project in the portfolio, included not for its complexity but for what it represents: the starting point of a journey that leads to complete design systems and products in production.
A functional app that eliminates manual calculations when splitting expenses among multiple people. The project fulfilled its goal as a course final project and as a solution to a real need, family Christmas gatherings now have a tool.
I would start with wireframes of the two critical flows before writing any line of code. I would also separate business logic from the interface more clearly from the start, today I would do it with React or with a cleaner architecture, not with global functions in vanilla JavaScript. And I would add the ability to save or directly share the summary, which is exactly what you need when you've just calculated who owes whom.