I created this website because I wanted to have a personal presence on the internet. It gives me the opportunity to share more about myself — and especially about my work — than a traditional CV can convey.
I also wanted a place to present my scientific publications in a structured and accessible way.
Beyond that, I was looking for a space to write about IT architecture topics that are relevant across many systems: complex, widely shared challenges where I can express my perspective without revealing sensitive details about my concrete projects or day-to-day work.
After deciding to build my website, the next step was choosing the right tools for it. My requirements were clear:
I wanted to present my CV and publications, maintain a blog with a moderate posting frequency — perhaps one or two posts per month — and use a layout that looks clean and appealing. At the same time, the solution needed to be easy to maintain, both in everyday operation and when applying updates.
As an IT architect, I began by gathering the requirements for selecting an appropriate tool.
I already had a small website that I had written directly in static HTML and hosted by a good friend of mine. While this setup worked, it also revealed several limitations. From that experience, I realized that:
This led me to the following requirements:
Since I already had a GitHub account, GitHub Pages quickly emerged as a strong candidate that met all these requirements.
GitHub Pages uses Jekyll to transform Markdown into a complete website. A wide range of themes is available, making it easy to build pages with a clean and appealing design.
With this initial idea in mind, I conducted a brief evaluation.
Two key questions emerged:
After some research, I arrived at the following answer to question (1): Jekyll is still a solid choice.
For question (2), my research led to a clear conclusion: GitHub is a very convenient choice.
The combination of Jekyll and GitHub fulfills my requirements:
My first steps were straightforward and followed the GitHub Pages documentation.
I began by creating an index.md file as the main page and configuring GitHub Pages to build directly from my main branch.
To use my own domain and set up the CNAME, I needed to:
After that, I added additional pages — About Me, Publications, and Imprint, Disclaimer, and Privacy Policy — and linked them together within the Markdown files.
Everything worked, but the design was extremely basic. On the other hand, I now had all my content stored as clean Markdown files, without any external dependencies — a solid foundation to build upon.
To improve the design of my website, I began searching for a suitable theme and quickly discovered Minimal Mistakes.
Google’s AI describes Minimal Mistakes as follows (March 2026):
“Minimal Mistakes is a true ‘workhorse’ among Jekyll themes. It is less intended for playful, highly visual lifestyle blogs and instead shines where structure, information, and depth of content are the main focus.”
Microsoft Copilot summarizes it this way (March 2026):
“Minimal Mistakes is perfect for websites that need to organize and present substantial content cleanly and readably, without the overhead of a full CMS such as WordPress.”
Encouraged by these assessments, I began exploring the technical details of the theme.
The minimal starter repository for Minimal Mistakes — mm-github-pages-starter — proved extremely helpful. By studying its structure and configuration, I was able to iteratively reorganize and improve my own website.
Along the way, I learned that Markdown pages typically begin with a front matter block — a concept used by most static site generators, including Jekyll. A wide range of parameters is available to control layout, metadata, and behavior. Another essential component is the Jekyll configuration file, _config.yml.
By asking LLMs about the specific parameters used these configurations, I gained a solid understanding of how Minimal Mistakes works and how to tailor it to my needs.
As a former software developer, I have always appreciated the concept of staging environments — the idea that every change destined for production should first be deployed to at least one production-like test environment. Applied to my website, this would mean deploying changes to a test site before updating the real one.
However, GitHub Pages’ simple integration does not natively support such a staging concept. It would be possible to approximate it by using two separate repositories:
After successful testing in DEV, a GitHub Action could synchronize the latest changes to PROD.
However, I decided not to pursue this relatively complex setup and instead opted for a much simpler approach.
I follow the GitHub Flow branching strategy. GitHub Flow consists of a single permanent main branch and short-lived feature branches for changes:
My use case was straightforward:
I wanted to present my CV and publications, maintain a blog with a moderate posting frequency — perhaps one or two posts per month — and use a layout that looks clean and appealing.
The combination of Jekyll, the Minimal Mistakes theme, and GitHub Pages meets all of my requirements:
By omitting an explicit staging concept, I can rely on the very simple and efficient GitHub Flow, which keeps my workflow lightweight while still maintaining structure and clarity.
]]>