Self Evaluation

1. Giacomo Lancerin

This project represents one of my first experiences developing a full-stack web application completely autonomously, coming from a bachelor in Economics. Undertaking a project that required managing a backend API, database interactions, and a frontend interface was a significant challenge, but one that provided immense learning value.

Thanks to my internship as a Data Scientist and AI Developer at Technogym, I had the opportunity to learn many coding best practices from the professional world. This experience proved invaluable for the project, as I was able to apply industry-standard approaches to version control, deployment, documentation, and code quality throughout the development process.

1.1 Strengths

  • End-to-End Implementation: I successfully designed and deployed a functioning application that solves a real-world problem. The system handles complex logic like expense splitting and debt simplification, which required careful algorithmic thinking.
  • Modern Tech Stack: I utilized a modern, industry-standard stack (FastAPI, Streamlit, Pydantic) rather than relying on simpler, legacy tools. This required learning asynchronous programming concepts and stateless API design.
  • User-Centric Design: I designed the application with careful attention to creating a simple, clear, and intuitive user experience. The interface was built to be easy to navigate, with straightforward workflows and immediate visual feedback. I approached the design by first building something I would want to use myself, ensuring that every feature felt natural and accessible.
  • Code Quality and Best Practices: I maintained a clean separation of concerns by isolating the database logic (backend/db), API routes (backend/routers), and frontend UI (frontend/pages). This modularity makes the codebase maintainable and scalable. Drawing from my internship experience, I implemented proper naming conventions for branches, comprehensive documentation through docstrings and API specs, and established a robust pull request workflow with automated checks. These practices ensured code quality and facilitated collaboration.

1.2 Weaknesses

  • Testing Depth: While I implemented basic unit tests for the backend logic, the frontend lacks automated testing. End-to-end tests (simulating a user logging in and adding an expense) are currently manual, which increases the risk of regressions during updates.
  • Database Scalability: The current use of SQLite is excellent for development and small-scale deployment but is not suitable for high concurrency. As a file-based database, it risks “database locked” errors if multiple flatmates attempt to write data simultaneously.
  • Limited Error Feedback: In some edge cases (e.g., network timeout between frontend and backend), the user receives a generic error message rather than specific guidance on how to retry.

1.3 What I Learned

The most significant learning from this project was understanding how to build an application from scratch starting from a real need. Throughout the development process, I made a conscious effort to adhere to software engineering best practices, from code organization and version control to testing and documentation, drawing on the professional standards I learned during my internship.

Perhaps most importantly, I learned to navigate the ecosystem of third-party services required to make an application truly accessible. I had to figure out and adapt to deployment platforms like Railway for the backend and Streamlit Community Cloud for the frontend, understanding their constraints and how to make them work together seamlessly. This process of transforming the project from an idea into a real product that others can actually use was challenging but essential.

The collaboration with Matteo also taught me how technical implementation and business requirements must work hand-in-hand—his input on user needs and edge cases helped me refine the technical implementation significantly.

2. Matteo Minnucci

I was in charge of defining the business logic and understanding the user needs for Flatmates. My contribution focused on translating household management problems into technical requirements and ensuring the software’s logic aligned with how flatmates actually need to manage expenses and settle debts.

2.1 Strengths

  • Debt Simplification Algorithm: Together with Giacomo, we designed and validated the core algorithm that minimizes the number of transactions needed to settle all outstanding debts. I contributed to the conceptual design, while Giacomo handled the implementation and refinement.
  • Domain Knowledge: I conducted informal interviews with flatmates to understand pain points in shared living. This research informed key decisions, like implementing a flexible expense splitter and designing the dashboard to show actionable debt information immediately.
  • Business Requirements and User Experience: I focused on defining how the application should behave from the user’s perspective. This included specifying the expense modeling logic—how expenses should be split, how reimbursements should work, and what edge cases needed to be handled. Giacomo’s technical expertise was invaluable in translating these requirements into working code and identifying implementation constraints I hadn’t considered.
  • Report and Documentation: I took the lead on writing project documentation and reports, explaining the business rationale behind design decisions, user stories, and the problem domain. When technical explanations were needed, Giacomo provided support in articulating architectural choices and technical trade-offs.

2.2 Weaknesses

  • Limited Technical Implementation: While I designed the debt simplification algorithm the actual implementation was handled and revised by Giacomo. This meant that some of my assumptions had to be validated during the development process.
  • Incomplete Shopping List Logic: My initial specification for the shopping list was simplistic. I didn’t anticipate edge cases like “what if someone buys a partial quantity?” or “how should items be prioritized?”

2.3 What I Learned

I realized that software is not just about code; it’s about understanding the problem deeply. Before any implementation, I spent time thinking about the problem domain and user needs. This “business analysis” phase prevented costly rewrites later. I also learned that domain experts and engineers must collaborate continuously; a good idea in theory can fail in practice due to implementation constraints.

This site uses Just the Docs, a documentation theme for Jekyll.