Kosmetik Profi
Website and admin panel for a cosmetology practice in Münster — a bilingual price list, booking for two locations, and an admin the practice runs on its own.
Overview
A cosmetology practice with two studios in Münster needed one clear place for its treatments, prices and bookings — in German and English.
The practice offers face, body, nail and hair treatments, distributes a professional cosmetics line in Germany and trains other cosmetologists. Its price list runs to 53 services in six categories, and prices change often enough that they couldn’t live in hard-coded pages.
I built the site from a provided design: the public page and the backend behind it. The admin panel I designed as well as built, so the owner can keep every service and price current without calling a developer.
What’s in it
Architecture
One small server renders every page. Visitors and the admin panel read and write the same data, so a price changed in the admin is live on the next page load.
How it was built
The first version took two days. The repository starts on 15 December 2024 with the public page and the admin already working, and by the next day the admin had its final three screens: login, categories and services. It went live in January 2025, packaged in Docker.
Pages are rendered on the server with NestJS and Handlebars. A local business needs a page that loads fast and shows up in search, not a client-side app. The data sits in SQLite through TypeORM: the right size for one practice, with no separate database to run.
I also set up where it runs. I helped the practice get its domain, configured the DNS, and set up an OVHcloud VPS with Coolify, which builds the Docker image and redeploys the site whenever a change is merged into the main branch. It’s a minimal DevOps setup, but a complete one: a merged pull request reaches the live site without anyone logging into the server.
I’ve kept maintaining it since: “from” prices and the location picker with EasyWeek booking in 2025, legal pages and shareable category links in 2026. In October 2026 a responsive pass fixed prices colliding with long German service names and lined the cards up across each row with CSS subgrid.
My review
I picked this stack because the website did not need anything super special. It did not need React and Next.js. At the time, I have been already building applications with NestJS as backend while learning it from Udemy courses, official documentation and practise. It is a very convenient framework, and coming from Java Spring that I have been learning in university for quite a while, the NestJS was the best way for me to build backends.
I decided to try out Handlebars as a frontend technology for a few reasons: I wanted to try something new for a simple project, I heard a lot of template engines at that time, especially after work with Thymeleaf and it was an interesting experience for backend to serve the HTML as in old good times.
I can say that it was a pure joy to build on that stack and each time I return to the website to maintain it, I can easily understand the code I wrote at that time. And even after a few years after I built it and moved fully to React, I can still understand the application code because it was very straightforward and I can say I wrote it very well. I usually dont say that about my older apps.