About This Site

For a long time, my professional story lived in one familiar format: a carefully edited DIN A4 document listing roles, dates, qualifications and responsibilities. It did the job. It never felt like me.

A CV is good at answering what someone has done. It’s much weaker at showing how they think, what they care about, or how seemingly unrelated parts of a career actually connect. In my case, those parts include agile delivery, product thinking, UX, frontend development and a broad technical background. Squeeze all of that into two pages and the context is the first thing to go.

So I wanted something more personal than an online copy of my résumé. A place where people could get a sense of both the profession and the person behind it.

A Portfolio for an Agile Coach?

Sounds simple enough, until you actually go looking for personal websites by Scrum Masters and Agile Coaches. There are plenty of capable people out there with genuinely useful content, but visually, almost everyone lands on the same safe pattern: explain the frameworks, list the certifications, close with a contact form. Barely anything feels modern, distinctive, or like an actual person made it.

That’s not a knock on the profession. It’s just a hard thing to visualise. Designers get to show identities, interfaces, typography. Illustrators have their artwork. Developers can point to running applications and real code. But what does a Scrum Master put in a portfolio? A stack of workshop boards? Photos of sticky notes? A velocity chart?

I decided the site itself had to be the example. Its structure, language and interactions would have to show how I connect people, products and technology, not by dressing agile work up as something it isn’t, but by giving an often abstract job a clearer voice and a more memorable shape.

The Design Was Already Waiting

At first I didn’t know exactly what I wanted to publish. The positioning was still taking shape, and I couldn’t decide which part of my background should lead the story. Then I dug up an old Adobe XD concept I’d made years earlier and never shipped.

Two views from the earlier Adobe XD portfolio concept: an open navigation and the original hero design.

That design belonged to a different stage of my career, its message was built around UX and development, but the visual idea still felt right the moment I saw it again: the dark canvas, the strict grid, the oversized typography, the vertical details, the hand symbol. I fell for it a second time.

Instead of reproducing it pixel for pixel, I used it as a starting point. The current site keeps the character but tells a different story. UX and technology are still part of my background, but now they support a sharper proposition around agile delivery, team enablement and ownership.

That rediscovery also solved a branding problem I didn’t expect to solve so easily. I didn’t need to invent a polished identity from scratch. I already had a visual language with real history behind it. I just had to evolve it into something that represents who I am now.

Returning to the JAMstack

This project also gave me an excuse to try a newer generation of tools from the JAMstack ecosystem.

I’ve worked with large, capable content-management systems and understand exactly why organisations need them. I also know how much machinery comes bundled in: databases, server-side rendering, plugin ecosystems, update paths, layers of configuration. For a small personal site, all of that weight solves problems I simply don’t have.

What I like about the JAMstack approach is the flow of the work itself. Content and components live in the repository, pages get built ahead of time, and what ships is mostly static files. Dynamic behaviour is added on purpose, through JavaScript or external services, instead of being baked in as a permanent application backend by default. Less operational complexity, better cacheability, a smaller attack surface.

I’d already enjoyed building JAMstack sites with Gatsby and Bootstrap in the past. This time I wanted to move on from what I knew, question my defaults, and see how far the workflow had evolved. Beyond Gatsby, the current JAMstack landscape has plenty to explore: Next.js, Nuxt, SvelteKit, Eleventy and Hugo all take slightly different bets on rendering, tooling and how much JavaScript ends up in the browser.

Why Astro

Astro turned out to be a natural fit, because this site is, at its core, content. It ships static HTML for most of the experience and treats JavaScript as a deliberate addition rather than the default foundation for every page.

That distinction matters to me. The site does have interaction: navigation, page transitions, the hero animation, the agile-process popovers. But the articles, career history and service descriptions don’t need a client-side application just to exist. Astro components keep the project modular, and its islands architecture means interactive pieces stay focused while the rest of the page stays light.

The blog follows the same logic. Posts are Markdown files inside an Astro content collection. A schema validates their metadata, and that same content feeds the article pages, categories, tags, RSS feed and homepage. Writing stays separate from layout, with no database and no admin interface required.

Tailwind for the System, GSAP for the Moments

After years working with Bootstrap, I wanted to try Tailwind CSS’s far more compositional approach, and it turned out to suit this design particularly well. The visual identity rests on a handful of recurring decisions: spacing, borders, typography, grid proportions, a small brand palette. Tailwind keeps those decisions visible right next to the components, while shared CSS tokens hold everything together consistently across the site.

It also made iteration genuinely fast. The original Adobe XD grid translated cleanly into responsive rules I could test at different widths and adjust on the fly, without piling up a mess of one-off component classes.

For animation, I picked GSAP. Not to animate everything, but to put motion where it actually supports the site’s personality: the slot-machine sequence in the hero, the portrait reveal, transitions between pages and sections. The goal was rhythm and a bit of surprise, not friction between the visitor and the content.

From VS Code to Production

The source code lives on GitHub, which gives the project a simple, visible history of every decision. IONOS Deploy Now connects to that repository and turns every push to production into a repeatable build and deployment. For a static Astro project, that’s exactly the workflow I wanted: make a deliberate change, review it, commit it, and let the pipeline take it from there.

I built the whole thing in VS Code, with Codex running alongside me throughout. It helped me move faster: creating Astro components, restructuring Tailwind styles, tracing layout bugs, turning rough ideas into something I could actually click through. The value wasn’t skipping decisions. It was shrinking the gap between making one and seeing it live in the browser.

Honestly, that made the whole process feel a lot like good product work. I gave direction, constraints and feedback. The implementation moved fast, but the message, the trade-offs and the final call were still entirely on me.

A First Release, Not a Final Answer

This site started without a fully worked-out content plan or a polished brand message. Both showed up along the way: write a section, look at it in context, notice what rings false, try again.

What I ended up with is more than a digital CV, but it’s deliberately not a finished monument. It’s a first release of how I want to show up right now. The content will get sharper, the blog will grow, and a few interactions will probably change once real people start clicking around.

For now, what I’m actually curious about is the response. Does the site make an abstract profession feel more tangible? Does it connect my agile work with my technical and creative background? Does it help people understand how I might contribute, before they ever open the PDF version of my CV?

This is the first draft. Time to see what the feedback says.