LMU
Students

University Course

At one point we thought, why limit the capacity to us? There should be more students taking part in creating their own solution. From students, for students. So we talked to professors and PhDs and were able to host our own official class called „Full Stack App Development" for the winter and summer semester 2025.

We received over 30 applications from students to take the class and chose 8 to join the team. We had weekly meetings discussing progress, teaching concepts of modern frontend architecture, color theory and more.

Full Stack App Development Class Summer Semester 2025

Legacy Infrastructure

The outdated system doesn't only make it hard for students to look up information but also for our system to access it. There were no clean APIs and interfaces to access the information. So it was evident we had to build that ourselves, store the data on our side to not overwhelm the old system and bring the information into a new structure that can be used to populate a UI with information. This way we would have the whole data pipeline in control.

Learning Backend Development

Nobody on our team had ever written a backend. So the whole hosting, server, database, scraping, API thing was new to us. Even though my background is more on the UX side, I jumped head first into the topic and took responsibility of it since then.

User Communication

It was clear that the first release was missing some essential student features like checking available courses, calendar and news, due to lack of APIs and infrastructure from LMU. So we needed a way to show what the app can do, what is missing and actually give users a way to communicate their needs.

For this we added a wishlist, where they were able to see and vote on current ideas. This addressed the high expectations students have for an app, and also gave us a way to prioritize what we would implement next.

Language

The style I aimed for was modern, simple and mobile friendly. I took inspiration from other apps I very much enjoy using, like Revolut.

Design System

The fundament of all designs: our design system. It was handcrafted by myself in Figma, with auto layout, variables, components and variants. Supporting light and dark mode and over 100 custom components.

Design System Cover

The system was built in a way that can also be reproduced in code in our Flutter frontend. So when Paul and Lukas started with the frontend, the first step was to translate all the elements like colors, components etc. into a mirrored Flutter design system. This made designing and building UIs very fast.

Colors

All color palettes were custom created with a perceptually uniform colorspace called OkLCH on oklch-palette.vercel.app. This ensured accessibility and contrast over all colors for the same value. E.g. a yellow-10 has the same contrast asred-10.

Color Space Comparison (from Wikipedia)

Since our brand color is green, we chose it as our accent color which isn't ideal because it can get confusing with success states. The gray palette was also derived from that and inherited a greenish tint.

We added those palettes in a variable collection in Figma as primary color tokens and built a second semantic layer on top that was exposed to our design files.

Design System Color Variables

Animations

Animations are a great way to enhance the user experience. We used the design system to create a set of animations that are used throughout the app. Since simple easing functions don't reflect natural motions i decided to use spring animations. Those are based on the physics of a spring and feel more natural and organic.

Data Fetcher

For each topic like food, cinema etc. we added a time-scheduled scraper to the container which then collected the data and saved it in our database.

For some content like the libraries we had to deal with unstructured data, so we used LLMs to interpret what the website gave us and put it into a format we could save. Some websites were so cluttered it wasn't possible to solve with regex.

For the canteen menus we did a similar thing, they were automatically translated with DeepL. Generally our approach was to improve the data quality we got with other APIs. We also did that for the movies: we added information like IMDb ratings, movie posters, trailers etc.

Database

This was probably the hardest part, getting the relations right. Especially when you deal with translations, it isn't enough to just put a „title" column. We needed to create a new translation table with all fields that needed localization.

API

To implement the API fast I went with FastAPI. Each endpoint had its own Pydantic model which was also used as a response model, as well as a service layer to get the information from the DB and the router.

Some endpoints were protected and only accessible with API keys of different scopes. Some endpoints have a soft protection. For example, getting canteen dishes will return a result authenticated or not, but when a user is recognized it also returns the dish likes for that user.

Available endpoints can be found in the API documentation.

To make the API more responsive we would like to add a Redis cache database.

GitHub

We used GitHub not only as a version control tool but also for project planning. Issues were always connected to branches.

We also used GitHub Actions to automatically deploy the Docker containers and spin them up on staging/prod. This significantly improved our workflow since once something was merged with staging it would get deployed. To push to prod, another action took the staging Docker container, renamed it and published it over SSL on the prod server.

Content Management

There is some data you can't crawl... so you have to manage. We started content management with writing hardcoded values in the backend, then switched to API endpoints and finally settled on a CMS system. After some research we chose Directus (over Strapi) because it could be integrated into our current database.