Over the past month or so I have been working on Practice Logger, a full-stack web app designed to help music students log their practice sessions and give teachers a clearer overview of their students’ work. The app began as a simple practice-tracking tool, but has gradually grown into a role-based platform for students, teachers, and administrators. Once logged in, students can add practice tasks and convert them into timed practice sessions, allowing them to monitor both duration and progress. Teachers can assign tasks to students through a dedicated Teacher Dashboard, which also includes a weekly progress ranking. There is also an Admin panel for maintaining user accounts, changing roles, activating or disabling accounts, and, soon, resetting passwords. The backend is built with FastAPI, which provides the API service for authentication, user management, tasks, sessions, and teacher/admin functionality. Authentication is handled using the OAuth2 password flow, hashed passwords, and JWT bearer tokens. Users register and log in through the auth routes, after which their role determines which parts of the app they can access. The API uses standard REST-style routes: students and teachers can retrieve tasks and sessions through GET routes, create new records with POST, update existing data with PUT, and remove records with DELETE. Admin users can manage accounts through PATCH routes, including changing roles and disabling accounts where necessary. One of the advantages of FastAPI for this project is its automatically generated Swagger documentation. This makes the API easy to explore, with routes grouped by tags and example JSON payloads shown clearly in the browser. FastAPI’s use of Pydantic validation is also very useful, as it helps enforce clear request and response structures and catches potential errors before they spread through the application. For data persistence, I originally used SQLite. As the project grew, however, I moved to PostgreSQL, which felt more suitable for a deployed full-stack application and better prepared for future development. The database currently contains users, tasks, and sessions tables, with relationships allowing users to own tasks and tasks to have associated practice sessions. SQLAlchemy is used as the bridge between the API and the database, allowing the application to construct queries, manage relationships, and manipulate data in a structured way. At the moment, all teachers can view the available student data, which is acceptable for a small demo version. A future improvement would be to introduce a clearer relationship between teachers and their own students, so that each teacher only sees the students assigned to them. This would likely involve an additional table or relationship model to support a more realistic multi-teacher environment. The frontend is built with React using Vite. I used a separate API service layer to handle communication between the React components and the FastAPI backend. When users visit the app, they can register or log in, with the generated JWT stored locally so they remain signed in across sessions. After logging in, users are taken to a dashboard based on their role. The student dashboard includes a TaskForm component for adding new tasks, a TaskList for displaying active and completed tasks, an ActiveSessionPanel for showing the task currently being practised, and a SessionHistorySection for reviewing completed practice sessions. React works well for this kind of interface because its state hooks allow individual sections of the dashboard to update immediately without requiring page reloads. For deployment, I initially used Render for both the API and PostgreSQL database. Although this worked, I noticed that the backend could take a long time to respond after periods of inactivity, which made the public demo feel less reliable. I therefore migrated both the API and database to Railway, which improved responsiveness and removed the cold-start delays I was seeing. The frontend is deployed separately on Netlify, with the backend connected through a VITE_API_BASE_URL environment variable. The live app can be viewed here: Practice Logger The backend API can be viewed here: Practice Logger API The source code is available here: Frontend source code and Backend source code This project has taught me a lot about building frontend and backend architectures in different languages and connecting them into a working full-stack application across multiple web services. I have gained more experience with validation, authentication, data modelling, deployment, and database persistence, all of which will be valuable in future projects. Although Practice Logger started as a relatively simple idea, it continues to grow as I find new ways it could help my own students and other teachers. The next features I plan to add include linking multiple tasks within a single practice session, adding an admin password reset tool, and turning the app into a PWA so students and teachers can install it on a phone or tablet and access it more easily.