The Stack I Want to Build#
In the previous post, I wrote about why I started building on the side — the generalist background, the shift that makes solo building possible, and why this blog exists. That was the why. This post is the what.
If I want to become a solopreneur, I need more than motivation. I need a system. A repeatable way to go from idea to deployed product without spending weeks on boilerplate, infrastructure, and tooling decisions every single time. The goal is clear: when the next idea hits, I want to go from zero to a running application in days, not months.
So the question becomes: what do I actually need to learn and build to get there?
The Tech Stack: Go and Flutter#
I’ve spent most of my career writing C#. It’s a language I know inside out, and the obvious move would be to stick with it — use Blazor for the web frontend, MAUI for mobile, ASP.NET for the backend. The whole Microsoft ecosystem, batteries included.
But I’m deliberately choosing something different. Go for the backend, Flutter for the frontend.
Why not C#? Go is faster, produces smaller binaries, and is simpler to reason about. There’s no heavy runtime to ship, no complex dependency injection frameworks to wire up. For the kind of lean backend services a solo builder needs, Go fits better than the enterprise-oriented .NET ecosystem. It’s a language built for exactly this: small, fast, deployable services.
For the frontend, I chose Flutter over the alternatives I’ve actually used. I’ve built projects in React and Next.js — the JavaScript and TypeScript experience never clicked for me. It works, but I didn’t enjoy it. MAUI was the other option, but the XML-based UI markup feels dated after years of working with more modern approaches. Flutter gives me what I want: a strongly typed language with Dart, multi-platform capabilities covering web, iOS, and Android from a single codebase, and a declarative UI framework that doesn’t involve XML or JavaScript. No compromises on type safety, no context-switching between languages.
The Template System#
Picking a tech stack is just the beginning. What I really need is a project template — a ready-to-go starting point that I can clone and customize for each new idea.
This template needs to include the things every product needs but nobody wants to build from scratch: authentication, payment integration, push notifications, error handling, CI/CD pipelines. The boring but critical infrastructure that eats weeks of development time if you start from zero every time.
The vision is straightforward. New idea? Clone the template. Customize the domain logic. Deploy. The plumbing is already there — auth works, payments work, the pipeline pushes to production. I can focus entirely on what makes the product unique instead of rebuilding the same foundation over and over.
I don’t have this yet. Building it is one of the first major projects on this blog.
Infrastructure: The Long Road on Purpose#
You might be wondering why I’m not just using Vercel, Railway, or one of the many backend-as-a-service platforms that would let me deploy with a git push and forget about infrastructure entirely. It’s a fair question — those tools exist specifically to solve the problems I’m describing.
The honest answer: I want to learn. Terraform for infrastructure provisioning. Ansible for configuration management. Kubernetes for orchestration. ArgoCD or FluxCD for GitOps-based deployments. These aren’t just resume keywords — they’re tools I want to understand deeply enough to run in production.
There’s a practical reason too. I already run a homelab with a Proxmox server, and most of it was set up by hand. Every configuration change is a manual SSH session. Every update is a reminder that I should have automated this months ago. Learning GitOps for my side projects means I can turn that same knowledge back on my homelab and transform it from a hand-crafted snowflake into a properly automated, version-controlled infrastructure. Two problems, one learning path.
So yes, I’m taking the long road. But it’s the long road that leads somewhere useful.
The Workspace: Ready in Minutes#
All of this needs a development environment that’s fast to set up and portable across machines. Here’s what that looks like right now and where it’s heading:
Today: I work on a Linux VM running on Proxmox, accessible from anywhere through Guacamole. Dev containers isolate each project, and Claude Code in the CLI is my AI pair programmer. VS Code is still my editor — for now.
Where I’m heading: A fully terminal-native setup managed by chezmoi. Zsh as my shell, tmux for session management, neovim as my editor. The goal is to clone my dotfiles onto any Linux machine — a fresh VM, a cloud instance, a dev container — and have my complete environment ready in minutes. No GUI dependencies, no extension marketplaces, no mouse required.
I’m not there yet. I’m learning neovim and tmux in parallel while shipping actual work in VS Code. The transition is happening gradually, not as a big bang migration. Practicality first.
The First Project: A Time Tracker#
Grand plans need a starting point, and mine is deliberately small. My first project will be a time tracking app. I’ve tried the existing options — Toggl, Clockify, Harvest, and others — and none of them fit exactly how I want to track my time across freelance work and side projects.
It’s the perfect first project: small enough to build solo, useful enough to actually use daily, and complex enough to exercise the full stack — Go backend, Flutter frontend, authentication, data persistence, maybe a simple API. It’s also the project where I’ll build out the first version of my template, extracting the reusable parts as I go.
What’s Next#
This is the roadmap. Not a rigid plan with deadlines, but a direction. I’ll start with what I can ship today — VS Code, dev containers, Claude Code — and evolve the workflow and infrastructure as I learn.
The blog will document all of it: the dev environment evolution in The Solo Stack, the tooling experiments in Building with AI, and the bigger picture here in The Journey. Some posts will be polished guides. Others will be honest accounts of getting stuck, changing course, and figuring things out in real time.
The stack isn’t built yet. But now you know what I’m building toward.
