Von der Idee zur App: Tripster – Reisekostenverwaltung für Gruppenreisen
English Version
Im Rahmen eines Softwareentwicklungsprojekts an der TH Wildau entwickelte unser siebenköpfiges Team im Laufe eines Semesters eine Web-Anwendung mit dem Namen **Tripster**. Ziel war es, eine digitale Lösung für die gemeinsame Reisekostenabrechnung zu schaffen. Die Anwendung sollte Gruppenmitgliedern ermöglichen, Ausgaben transparent zu erfassen und automatisch eine faire Aufteilung der Kosten zu berechnen.
Herausforderungen für das Projekt
Zu Beginn des Semesters standen wir vor einer komplett leeren Ausgangslage. Wir hatten weder ein Thema noch eine klare Vorstellung davon, wie unser Projekt aussehen könnte. Die erste große Hürde war daher die Themenfindung. Dabei stellte sich insbesondere die Herausforderung, ein Thema zu finden, das den Erwartungen und Interessen aller sieben Teammitglieder gerecht wurde. Zusätzlich musste sichergestellt werden, dass das gewählte Thema innerhalb eines Semesters realistisch umsetzbar war – also weder zu einfach noch zu komplex.
Nachdem wir ein Thema gefunden hatten und in die eigentliche Entwicklungsphase übergegangen waren, traten neue Herausforderungen auf. Das Arbeiten in einem vergleichsweise großen Team von sieben Personen erforderte ein hohes Maß an Koordination und Kommunikation. Eine der zentralen Aufgaben war die sinnvolle und faire Verteilung der Aufgaben unter den Teammitgliedern. Dabei war es wichtig, individuelle Stärken und Interessen zu berücksichtigen. Zudem mussten vereinbarte Deadlines eingehalten werden, um einen kontinuierlichen Fortschritt zu gewährleisten. Die Planung und Durchführung der einzelnen Sprints, also die Aufteilung des Projekts in überschaubare Arbeitspakete, stellte ebenfalls eine nicht zu unterschätzende organisatorische Aufgabe dar – insbesondere im Hinblick auf das wöchentliche Arbeitspensum jedes Einzelnen.
Herangehensweise
Wir starteten mit Sprint 0, in dem der Fokus vollständig auf der Themenfindung und der allgemeinen Projektplanung lag. Jedes Teammitglied brachte eigene Ideen ein, die anschließend gemeinsam diskutiert wurden. Am Ende entschieden wir uns demokratisch für eines der vorgeschlagenen Themen. Nach der Themenwahl besprachen wir erste Herangehensweisen und legten fest, wie wir die Aufgaben im weiteren Verlauf strukturieren wollten. Ein wichtiger Punkt war auch die Verteilung der Gruppenrollen, wie zum Beispiel Projektleitung, Backend- und Frontend-Entwicklung oder Testing.
In Sprint 1.1 ging es darum, eine erste Version der Web-App zu erstellen, allerdings noch ohne funktionale Logik. Der Fokus lag auf dem Aufbau der Benutzeroberfläche und einem groben Design der Anwendung. Rückblickend war dieser Sprint inhaltlich etwas schwach gefüllt. Die ersten technischen Fortschritte waren zwar sichtbar, reichten aber nicht aus, um ein stabiles Grundgerüst für die nächsten Sprints zu schaffen.
Sprint 1.2 brachte einen deutlichen Schub im Projektfortschritt. Die Oberfläche wurde responsiv gestaltet, sodass sie auf verschiedenen Endgeräten nutzbar ist. Parallel dazu setzten wir die Datenbank auf, die als Grundlage für alle Backend-Funktionen dienen sollte. Auch das User-Management wurde implementiert, sodass Benutzerkonten erstellt und verwaltet werden konnten. Erste Seiten wurden nun auch mit der Backend-Logik verknüpft, was die Anwendung funktional erweiterte.
In Sprint 1.3 lag der Fokus auf der Fertigstellung der restlichen Backend-Funktionen. Sobald diese abgeschlossen waren, konnte die gesamte Anwendung auf einem Server gehostet werden, sodass alle Teammitglieder und später auch Dritte darauf zugreifen konnten.
Sprint 1.4 diente hauptsächlich dem Bugfixing. Wir testeten die Anwendung ausführlich, identifizierten Probleme und Fehler und arbeiteten diese systematisch ab, um die Qualität der finalen Version sicherzustellen.
Sprint 2.1 konzentrierte sich auf eine umfassende Neugestaltung des Designs der gesamten Anwendung, um sie innovativer und moderner zu machen. Parallel dazu wurde die Mehrsprachigkeit erweitert, indem Englisch und Spanisch als zusätzliche Sprachen implementiert wurden. Die Funktionalität des Kreisdiagramms wurde verbessert, ein neues Logo erstellt und die Avatare aktualisiert.
Sprint 2.2 führte eine Gruppenauflistung ein, die es Benutzern ermöglicht, einfach zwischen verschiedenen Gruppen zu wechseln. Ein Benachrichtigungssystem wurde hinzugefügt, um Benutzer über Aktivitäten in ihren Gruppen zu informieren. Labels für Ausgaben wurden implementiert, um eine bessere Kategorisierung zu ermöglichen, und ein Aktivitäts-/Kartentab wurde eingeführt.
In Sprint 2.3 wurde die Aufteilung von Ausgaben verbessert, das Benachrichtigungssystem erweitert und die Währungsunterstützung implementiert. Exportfunktionen für PDF und Excel wurden hinzugefügt, Pop-ups überarbeitet, App-Einstellungen eingeführt und ein Dunkel-/Hellmodus implementiert.
Sprint 2.4 transformierte die Anwendung in eine Progressive Web App (PWA), die auf mobilen Geräten installierbar ist. Push-Benachrichtigungen wurden hinzugefügt, und verschiedene Wrapper-Funktionen für eine bessere Benutzererfahrung implementiert.
Sprint 2.5 widmete sich der finalen Fehlerbehebung, der Verbesserung der responsiven Gestaltung und der Implementierung eines Cache-Handlers für bessere Leistung.
Lösung
Am Ende unserer zehn Sprints konnten wir eine funktionierende Web-App mit dem Namen Tripster präsentieren. Aufbauend auf den Ergebnissen der vorherigen Entwicklungsphasen wollten wir eine einfache Lösung für ein Problem schaffen, das viele aus dem Urlaub kennen: Wer hat was bezahlt und wer schuldet wem wie viel?
Mit Tripster können Gruppenmitglieder während einer Reise ihre Ausgaben eintragen, diese bestimmten Kategorien zuordnen und festlegen, für wen die Kosten gedacht waren. Am Ende zeigt die App automatisch an, wie viel Geld innerhalb der Gruppe ausgeglichen werden muss. Dadurch lassen sich Unklarheiten vermeiden und die Abrechnung am Ende des Urlaubs wird deutlich einfacher und fairer.
Technisch basiert Tripster auf einer Kombination aus einem modernen Frontend (React) und einem stabilen Backend mit Datenbankanbindung. Die Anwendung ist responsiv gestaltet und daher sowohl auf Desktop- als auch auf mobilen Geräten nutzbar. Die Nutzerverwaltung ermöglicht es Gruppenmitgliedern, eigene Accounts anzulegen und sich spezifischen Reisegruppen anzuschließen, wodurch die Anwendung auch für wiederholte Nutzung über verschiedene Urlaube hinweg geeignet ist.
Fazit
Rückblickend war das Projekt eine wertvolle Erfahrung – sowohl im technischen als auch im organisatorischen Sinne. Wir konnten nicht nur unsere Fähigkeiten in den Bereichen Webentwicklung, Datenbankdesign und agiler Projektarbeit vertiefen, sondern lernten auch, wie entscheidend klare Kommunikation und abgestimmte Teamarbeit in größeren Gruppen sind. Besonders stolz sind wir darauf, dass wir innerhalb eines Semesters eine funktionierende und benutzerfreundliche Anwendung entwickeln konnten, die ein reales Problem vieler Reisender adressiert. Trotz kleiner Rückschläge, technischer Hürden und der Herausforderung, die Arbeit im Studium mit der Projektarbeit zu vereinbaren, ist es uns gelungen, eine durchdachte Lösung umzusetzen.
Das Projekt hat uns gezeigt, wie wichtig es ist, iterativ zu arbeiten, regelmäßig Feedback einzuholen und flexibel auf neue Anforderungen oder Probleme zu reagieren. Insgesamt blicken wir mit Zufriedenheit auf die Entwicklung von Tripster zurück – und vielleicht wird die Anwendung ja sogar bei der nächsten gemeinsamen Reise unseres Teams zum Einsatz kommen.
Für eine detaillierte Übersicht aller Issues und ihrer jeweiligen Beiträger, die während der Entwicklung des Projekts bearbeitet wurden, siehe die Datei CONTRIBUTING.pdf.
Screenshots
Hier sind einige Screenshots der Tripster-Anwendung, die die verschiedenen Funktionen und Benutzeroberflächen zeigen:
Startseite und Anmeldung
Gruppenverwaltung und Ausgaben
Zahlungen und Benutzerprofile
Werbespot
From Idea to App: Tripster, Expense Management for Group Travel
As part of a software development project at TH Wildau, our seven-member team developed a web application called Tripster over the course of a semester. The goal was to create a digital solution for shared travel expense management. The application was designed to allow group members to transparently record expenses and automatically calculate a fair distribution of costs.
Challenges for the Project
At the beginning of the semester, we faced a completely blank slate. We had neither a topic nor a clear idea of what our project might look like. The first major hurdle was therefore finding a topic. The challenge was to find a topic that met the expectations and interests of all seven team members. Additionally, it had to be ensured that the chosen topic could be realistically implemented within one semester—neither too simple nor too complex.
After finding a topic and moving into the actual development phase, new challenges arose. Working in a relatively large team of seven people required a high degree of coordination and communication. One of the central tasks was the meaningful and fair distribution of tasks among team members. It was important to consider individual strengths and interests. Additionally, agreed deadlines had to be met to ensure continuous progress. Planning and executing individual sprints, i.e., dividing the project into manageable work packages, also posed a significant organizational challenge—especially in terms of each member's weekly workload.
Approach
We started with Sprint 0, where the focus was entirely on finding a topic and general project planning. Each team member contributed their own ideas, which were then discussed together. In the end, we democratically decided on one of the proposed topics. After selecting the topic, we discussed initial approaches and determined how we wanted to structure the tasks in the further course. An important point was also the distribution of group roles, such as project management, backend and frontend development, or testing.
In Sprint 1, the goal was to create a first version of the web app, albeit without functional logic. The focus was on building the user interface and a rough design of the application. In retrospect, this sprint was somewhat weakly filled in terms of content. The first technical progress was visible but not sufficient to create a stable framework for the next sprints.
Sprint 2 brought a significant boost in project progress. The interface was designed to be responsive so that it could be used on various devices. In parallel, we set up the database, which served as the basis for all backend functions. User management was also implemented so that user accounts could be created and managed. The first pages were now also linked to the backend logic, which functionally expanded the application.
In Sprint 3, the focus was on completing the remaining backend functions. Once these were finished, the entire application could be hosted on a server so that all team members and later third parties could access it.
Sprint 4 was mainly dedicated to bug fixing. We thoroughly tested the application, identified problems and errors, and systematically resolved them to ensure the quality of the final version.
Sprint 2.1 focused on a comprehensive redesign of the entire application's design to make it more innovative and modern. In parallel, multilingualism was expanded by implementing English and Spanish as additional languages. The pie chart functionality was improved, a new logo was created, and the avatars were updated.
Sprint 2.2 introduced a group listing, allowing users to easily switch between different groups. A notification system was added to inform users about activities in their groups. Labels for expenses were implemented to enable better categorization, and an activity/map tab was introduced.
In Sprint 2.3, expense splitting was improved, the notification system was extended, and currency support was implemented. Export functions for PDF and Excel were added, pop-ups were reworked, app settings were introduced, and a dark/light mode was implemented.
Sprint 2.4 transformed the application into a Progressive Web App (PWA) that can be installed on mobile devices. Push notifications were added, and various wrapper functions were implemented for a better user experience.
Sprint 2.5 was dedicated to final bug fixing, improving responsive design, and implementing a cache handler for better performance.
Solution
At the end of our ten sprints, we were able to present a functioning web app called Tripster. Building on the results of the previous development phases, we wanted to create a simple solution for a problem that many people know from vacations: Who paid for what, and who owes whom how much?
With Tripster, group members can enter their expenses during a trip, assign them to specific categories, and specify for whom the costs were intended. At the end, the app automatically shows how much money needs to be settled within the group. This helps avoid ambiguities and makes the settlement at the end of the vacation significantly easier and fairer.
Technically, Tripster is based on a combination of a modern frontend (React) and a stable backend with database connectivity. The application is designed to be responsive and can therefore be used on both desktop and mobile devices. The user management allows group members to create their own accounts and join specific travel groups, making the application suitable for repeated use across different vacations.
Conclusion
Looking back, the project was a valuable experience—both technically and organizationally. We were able to not only deepen our skills in web development, database design, and agile project work but also learned how crucial clear communication and coordinated teamwork are in larger groups.
We are particularly proud that we were able to develop a functioning and user-friendly application within one semester that addresses a real problem for many travelers. Despite small setbacks, technical hurdles, and the challenge of balancing academic work with project work, we managed to implement a well-thought-out solution.
The project showed us how important it is to work iteratively, regularly gather feedback, and flexibly respond to new requirements or problems. Overall, we look back with satisfaction on the development of Tripster—and perhaps the application will even be used on our team's next joint trip.
For a detailed overview of all issues and their respective contributors that were worked on during the development of the project, see the file CONTRIBUTING.pdf.