The Road to My Website

I’m writing this on a Monday in September, just three days after launching my personal website, damianpiatkowski.com. Friday afternoon software launches are a well-known meme in the development world, but this one felt more like the finale of a 16-month journey. Good thing I launched with an 80% test coverage, I guess, because the app is still live after the weekend, untouched since that single press of the deploy button (to my relief, it went much better than the meme-worthy end-of-week deployments).

I thought this would be a good moment to pause and take a snapshot, before I inevitably dive into all the features waiting in my pipeline. This post is partly for myself — to capture how I felt and where the website stood in its earliest days. But it’s also for you, dear reader. Maybe you’ve thought about having your own corner of the Internet. Perhaps after reading this, you’ll feel inspired to press the execute button and move beyond the idea stage. Let me take you through the steps that brought me here, writing a post on my own website, powered by its own blogging engine.

The Early Days

The reasons I set out to build damianpiatkowski.com — and why anyone might want their own little island on the Internet Ocean — deserve a separate article. The idea itself was born some two or three years ago, when it first seemed possible to pull off. From the very beginning, I wanted it to be 100% my own thing: no site generators, just a side project that would help me grow my skills and go beyond writing Python code in the automation context. By “possible,” I mean the moment when I could actually imagine the building process, when I finally understood the basic building blocks behind any website.

The scope changed over the years. At first, I imagined only a static portfolio site. Then, about two years ago, I got an interesting project at work that pushed me to expand my coding repertoire, focusing on building a full-blown platform with a strong back end. Getting to know the Flask framework in my daily job made my side-project idea evolve: I now wanted a blogging platform to stand alongside the static portion of the website.

Still, all of this unfortunately stayed in my head, with no execution. At the time, I thought that pre-paying for a year of domain registration might change that, hold me accountable, give me the kick I needed. But in the end, it only brought more disappointment — I couldn’t get myself to start coding in the evenings and weekends, and the registered domain just sat there, paid for but unused. Eventually, it expired, and another year slipped by.

It took a major life event and the emerging AI revolution to finally get the idea off the ground.

Second Baby, First Commit

Things change when you become a parent — in my case, for the second time. I don’t know what it was exactly — maybe the fact that I now had to provide for two children instead of just one — but I felt a growing motivation to finally treat my side project seriously.

My daughter was born on a warm spring day, a moment I still remember vividly. In the days that followed, I spent long hours at the hospital with my wife and the baby. During the downtime while they slept, I researched the tech stack and sketched out the website design — by talking to ChatGPT, of course.

ChatGPT had launched publicly a while earlier, but it was during that season — with GPT-4 — that I really started to take full advantage of it. I went beyond curiosity checks and began using it as what I like to call “Google on steroids.”

Armed with Flask skills and with a big web application as my main project at work, I was ready to scale up my knowledge, explore all the options, and go beyond the infrastructure limitations of corporate environments. The excitement of that “choose your stack” freedom in a side project really hooked me in those early days. I drafted features, planned everything beyond the coding — deployment pipelines, a virtual machine, even the costs behind each choice… you get the idea.

ChatGPT accelerated things in just the right way: the project still required my own expertise, but it shortened the path from a blank page to a working prototype I could build on.

Building While Bonding

I was lucky to have my second baby in Poland, where at the time I could take a total of three months off right after the birth by combining my paternity and parental leave with some vacation days. I will never forget that period of my life: long summer days, burping my baby with a Kindle propped up on a shelf so I could read hands-free, even at 5 a.m. when the sun was already up. Even though my days were centered on the baby, there was still plenty of downtime — and not having to think about my full-time job’s projects freed up mental space and let my creativity flow. For the first time, I could truly focus on my personal project and carve out time to code each day. That period definitely played a major part in getting damianpiatkowski.com off the ground, and I’m not sure I would be celebrating today if it hadn’t been for it.

The Grind

Then came the hardest and longest stage of the project — the grind. Once I returned to my full-time job, the project was pushed back to the sidelines, and it became a true test of perseverance. I had to make sacrifices: weekend naps skipped, dust collecting on my Nintendo Switch, not a single TV show since the second season of House of the Dragon in summer 2024. I had to make a mental shift, reprioritize, and carve out space for the side project in what was otherwise my leisure time. And it wasn’t easy — that voice in my head kept saying, “I deserve some rest after eight hours of work and looking after the kids.” Yet I still managed to squeeze in many late-night coding sessions once the children were asleep.

I would spend weeks deep in the back-end trenches, adding service and controller functions, writing integration tests, and not touching the front-end at all. Then would come a phase focused on presentation: tweaking layouts, planning the blog’s photo management pipeline (thumbnails, hero images, sizes, aspect ratios, and so on). Still, the back-end took center stage during the grind — especially the blog component of my app, the Google Drive–to-database processing pipeline, sanitization — all the invisible behind-the-scenes work I trusted would pay off later.

I entered this crucial stage with a few key assumptions:

• Clean Architecture: Having recently read “Architecture Patterns with Python” by Harry Percival and Bob Gregory, I wanted to apply clean layered architecture to this Flask app right from the start.
• Feature-rich MVP: I was determined to launch with most of the features I had drafted at the beginning — not just a portfolio with a blog, but also an admin panel with Google Analytics, logs, a CMS for blog post management, and even an automated GitHub Actions deployment pipeline. I wanted it all on Day 1.
• Test-Driven Development: Knowing the importance of a solid test suite — and actually enjoying writing tests — I was committed to maintaining good coverage rather than sacrificing quality for speed.

In the end, I did achieve a strong test suite and a clear separation of application layers, but the scope of version 1.0.0 had to be scaled down significantly.

Redefining MVP

The longer I worked, the clearer it became that I needed to scale down the scope of my launch vision. It can be draining to go too long without seeing results, so I knew I had to set a less ambitious finish line for version 1.0.0 and get there quickly. Once I had the portfolio with a working blog engine live, I was confident it would give me fresh motivation to keep going and iteratively add features in later versions. Plus, SEO authority would start building earlier. So the admin panel would have to wait, and my first deployments to the EC2 instance would be manual rather than automated. Not the end of the world.

Launch Days

The whole of August 2025 felt like the launch was finally within reach. I was confident this time — I just didn’t know the exact day, and that was fine. SEO work took longer than expected, since I was learning as I went and kept uncovering new things to optimize. Not a problem — good SEO was something I refused to compromise on for my launch. Getting familiar with the AWS ecosystem also took more time than I thought, but that too was exciting, a step into a brave new world.

But then one unexpected problem almost broke me. It was one of the toughest days of the journey — I felt on the edge of rage-quitting.

The culprit was Docker, making my virtual machine crash repeatedly. At first I didn’t know why: every time I started the app, the machine became unresponsive. I couldn’t even SSH into it. Every debugging attempt failed, including mounting its root volume to a helper instance and unmounting it again. I began to think the affordable t3.micro instance wasn’t going to cut it, and that I’d need to rethink the budget. But this was just a low-traffic side project — no way was I going to double the cost just to move from 1 GB RAM to 2 GB. “That’s a deal breaker!” I told myself.

It was a day full of desperate debugging and running numbers in my head, and it nearly broke me. But with some distance, I can now see it as a blessing in disguise — a huge learning opportunity.

The next day, with a fresh mind, I decided to ditch Docker. It didn’t feel great to abandon the industry standard, but I had to make a tough call. I was on a budget, and I wanted to see if I could make things work on that tiny 1 GB RAM machine I’d grown oddly attached to. Why not? I’d been working with venv setups for eight years. Sure, it wasn’t as clean and portable as Docker, but I was only running one Flask web app — it was manageable.

I also fine-tuned MySQL to match my actual needs — maybe the biggest resource saver of all. I stripped the config down to minimal memory limits and capped connections at 50. When was I going to have more than 50 concurrent visits anyway? And my first version only used a single table in the database. I didn’t need much.

I also discovered swap — what a lifesaver.

All that patient setup paid off. From crashing every EC2 instance I tried, I ended up with a stable system and healthy resource usage:

ubuntu@ip-172-31-40-0:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           914Mi       502Mi       162Mi       2.6Mi       427Mi       412Mi
Swap:          1.0Gi       151Mi       872Mi

As terrible as the previous day had been, this one was the exact opposite. I felt elated, my doubts cleared away. Sixteen months in, I wasn’t about to quit.

The Day It Went Live

On September 5th, just after 1 pm CET, I finally typed damianpiatkowski.com into a browser and was greeted by the welcome pitch of my landing page. Everything worked — and it felt unreal. An idea years in the making had finally materialized before my eyes. 202 commits and countless hours of work later (I really wish I had kept count — next project, I guess), my skills had grown considerably, and I now had my very own place on the Internet. I felt excited about the opportunities and directions it could take.

I hope this story inspires at least one person who’s hesitating to dedicate their precious, limited free time to a side project. While I haven’t yet tasted the fruits of the delayed gratification I’ve subjected myself to throughout this journey, I strongly feel that the regret of never trying would have been a much higher price to pay than “wasting” all those hours if the site ends up gathering digital cobwebs instead of real traffic.

Your vision might look different — maybe you don’t need a back end at all, or maybe you’re dreaming of building something entirely different, like an indie game or a productivity tool. Whatever it is, as long as you’re learning while doing it, you’re not wasting a single minute. You’re investing your energy into something deeply rewarding in the long run. Your favorite game or show will still be there a year from now — but the motivation to act on an idea might not.