Why I Started Building on the Side#
I’ve always been the person who learns too many things. In over two decades of working in tech, I’ve picked up programming languages, networking, virtualization, containerization, product management, and whatever else caught my attention along the way. I’ve written C#, Java, TypeScript, and Flash ActionScript. I’ve configured firewalls, set up hypervisors, designed product roadmaps, and debugged CI pipelines at 2 AM.
For most of my career, this felt like a problem. The industry rewards specialists. “Go deep, not wide” is the advice everyone gives. And there’s truth in it — a deep specialist can command higher rates, land more focused roles, and build a reputation around a single domain. Meanwhile, the generalist sits in meetings understanding everything at a surface level, always the person who could help but never the one who owns it.
I’ve had business ideas for years. Side projects I sketched on napkins, product concepts I talked through with friends, problems I knew I could solve if I just had the time, the team, and the resources. But that’s the thing — building a real product used to require all three. Time I didn’t have after client work. A team I couldn’t afford. Infrastructure that cost real money before a single user signed up. So the ideas stayed in notebooks, and I stayed a freelancer shipping other people’s visions.
Why Now Is Different#
Something has shifted in the last few years, and it’s not subtle. It’s a fundamental change in what one person can accomplish alone.
Cloud infrastructure that used to cost hundreds per month now runs on single-digit budgets. AI coding assistants don’t just autocomplete — they pair-program, scaffold entire features, and catch bugs before I do. Open-source tooling has matured to the point where the free tier of everything is genuinely powerful. Containerization means I can run a production-grade stack on a 20-euro VPS.
What used to require a team of five and a round of funding can now be done by one person with a laptop and an internet connection. The barriers that stopped me — time, team, money — haven’t disappeared entirely, but they’ve dropped by an order of magnitude. A solo builder in 2026 has more capability than a small startup had in 2015.
And here’s the part I didn’t expect: being a generalist is suddenly the biggest advantage. When you’re building alone, there’s no one to hand things off to. You are the backend developer, the DevOps engineer, the product manager, and the security reviewer. All those years of learning “too many things” weren’t a detour — they were preparation. The generalist’s curse turned into the generalist’s superpower, and I didn’t even see it coming.
No venture capital needed. No team needed. Just an idea, AI, cloud infrastructure, and two decades of broad experience that finally has a use case.
The Workflow That Got Me Here#
Speaking of those two decades — the way I work has changed almost as much as what I work on.
I started my career in the Windows world. Visual Studio was the center of gravity for years: C# projects, enterprise rewrites, the familiar click-debug-deploy cycle. Later it was VS Code for TypeScript and everything web. IntelliJ for Java. Always a GUI, always mouse-driven, always comfortable.
Over the past year, I’ve torn that entire setup apart. My development environment now runs on a Linux VM inside Proxmox on my homelab server. I work inside dev containers, with Claude Code as my primary AI assistant right there in the terminal. The whole thing is accessible from anywhere in the world through a Guacamole server — I can pick up exactly where I left off from any browser, on any device.
But I’m not stopping there. The next evolution is going fully terminal-native. Chezmoi for dotfiles management across machines. Zsh as my shell. Tmux for session management. Neovim as my editor. The goal is a completely portable, keyboard-driven environment that I can clone onto any machine and be productive in minutes. The mouse is becoming a relic of the past — and I say that as someone who avoided Vim for twenty years.
It sounds extreme, and maybe it is. But when you’re building solo, your workflow isn’t just a preference — it’s your competitive advantage. Every minute saved on tooling friction is a minute spent on the actual product.
Why This Blog Exists#
All of this is the reason knuth.info exists.
I needed a place to document the journey — not just the technical how-tos, but the thinking behind the decisions. Why I chose this stack. What worked and what didn’t. The honest version of what it’s like to build solo in 2026, without the startup mythology of overnight success and hockey-stick growth.
Here’s what you can expect. The Solo Stack covers the infrastructure side: building a hardened homelab, setting up dev environments, and the tools that make solo building possible. The Journey — the category you’re reading right now — is the personal side: the mindset shifts, the workflow evolution, and the bigger picture of why any of this matters. And Building with AI documents what it’s actually like to work with AI as a daily collaborator, not a novelty.
Follow Along#
If you’re a generalist who’s been told to specialize, a developer with side-project ideas collecting dust, or someone who’s curious about what one person can build with modern tools — this blog is for you.
This is the era of the generalist. The tools are ready. The barriers are lower than they’ve ever been. It’s time to build.
