Why I Still Build Side Projects (And What I'm Building Next)

Dev Leader Weekly 151

Aug 03, 2026

TL; DR:

Build the thing for yourself first
A thin paid layer beats abandonment
Free tools are still worth shipping
No livestream this week. Sorry!

Why I Still Build Side Projects (And What I’m Building Next)

I’m twenty-plus years into programming and about fifteen years into my career, and I am still building side projects. That is not an accident, and it is not nostalgia. Building things is still the fastest way I learn, and it is still the advice I give to almost everyone who tells me their resume feels thin.

But something has shifted for me lately. I’ve gotten to the point where if I am going to sink my limited free time into building something, I should at least be open to the idea of charging a couple bucks for it. Not building a business. Not quitting my job. Just putting a very thin layer on the front of something I was going to build for myself anyway.

That small mental shift turns out to be a surprisingly good cure for the “ooh, shiny” problem that kills most side projects.

You can check out my full thoughts on this in the video below:

Twenty Years In And I Am Still Building

Whenever someone tells me their resume feels weak -- they’re not employed yet, or they’re junior and applications keep going nowhere -- my answer is almost always the same. Go build something.

It works for two reasons. The obvious one is that it gives you something concrete to talk about instead of a list of technologies you have “familiarity with.” The less obvious one, and honestly the more important one, is that building things is how you actually learn. Reading about a pattern and shipping something that depends on that pattern are completely different experiences.

I have written about this before in the context of why side projects and soft skills keep coming up in interviews, and I stand by all of it. But I want to be clear that this is not advice I give from a distance. I am still doing it.

Most of my side project time goes into BrandGhost, which is my main thing outside of work. It takes up enough of my attention that I have pushed other things aside for it -- including making videos on my main YouTube channel for a stretch. There are only so many hours, and something has to lose.

But there is always a pile of other stuff I want to poke at.

The Free Things I Have Already Shipped

Before I get into what I want to build, here is what is already out there for free, because some of you might actually find these useful.

Needlr is a dependency injection and assembly-scanning library I put together. It is extremely opinionated. I am not planning to sell it, and I am not trying to convince anyone it’s the one true way. I build basically all of my C# stuff with plugin frameworks, and that pattern kept showing up over and over, so I extracted it. If you want to use it, great. If not, that’s completely fine. If you want to see the shape of it, I have walked through building modular .NET applications with Needlr’s plugin architecture.

Homebase came directly out of frustration. If you spend any time on social media, you have clicked a hundred “link in bio” links that drop you on a landing page full of other links. Linktree is one of the platforms that does this, and I was a paying customer for a while. Then I hit a problem where video previews were rendering as black thumbnails. There is no good reason a YouTube thumbnail should just fail to show up. I opened a support ticket, got the runaround for about a month, and eventually thought: I pay for this, and I could just build it myself.

So I did, in roughly a weekend. Homebase is on GitHub, it is free, you can clone it or fork it, and it is optimized for SEO, AEO, and GEO. You can add product links and a bunch of other things. And if you’re wondering how to configure it -- you point Claude or Copilot at the repo, tell it where your stuff goes, and it handles the config files.

A few MCP servers for Google Search Console, Google Keyword Planner, and Google Analytics. Google did not have official MCP servers for these, which still surprises me. Mine are vibe coded, and I believe I have versions in both C# and Go because I wanted to mess around. They’re on my GitHub. I genuinely hope Google ships their own and makes mine obsolete. If you want to understand what is actually happening under the hood in one of these, I have a full walkthrough on building MCP servers and clients in C#.

None of those are businesses. They’re scratch-your-own-itch projects that happened to be useful enough to publish.

The Thin Paid Layer

Here is where my thinking has changed.

I have a problem that I suspect a lot of you share: I could go build this, or I could go build that, and then something shinier appears and I drift toward it. The half-finished graveyard is real. Most side projects don’t die because they were bad ideas -- they die because nothing forces them across the line from “sort of works on my machine” to “actually usable.”

A thin paid layer is the forcing function.

The idea is simple. Build the thing for yourself, because you actually want it. Get it to the point where you would use it. Then put a very thin layer on the front -- pay a couple bucks, here’s a license key, done. If people pay, awesome. If nobody pays, I still have the tool I wanted.

What I am explicitly not doing is turning every idea into a full-fledged business with a marketing site, a support org, and a roadmap. That is a completely different commitment and it is the thing that makes people avoid starting at all.

Actionable Tip: pick the side project you have abandoned closest to “done.” Define the smallest version you would personally use every week. Ship that, and only that. Whether you put a paywall in front of it is secondary -- the point is having a definition of finished that isn’t “everything I imagined.”

What I Actually Want To Build Next

These are all deeply opinionated, and you might read them and think “why would anyone pay for that?” That’s kind of the point. I am building them for me.

A modern MySQL Workbench with an LLM attached. Workbench is being retired, and from what I have read the plan is a lighter-weight experience inside VS Code. That’s neat, but personally I want the actual Workbench form factor -- just less dated. And the thing I really want is to give a read-only connection to an LLM and have it optimize queries with me. Connect with whatever access level you want (admin, write, read-only), poke at your data, and then have an agentic back-and-forth about query plans. I already do a version of this by giving Copilot read-only database access and letting it run EXPLAIN and look for optimizations. I just want it to be a real tool instead of a workflow I re-assemble every time.

A personal finance planner built for two people. My wife and I keep separate accounts but operate with full transparency -- the only exception being gifts we’re trying to keep a surprise. If she asks what’s in my 401k, the answer is just the number. We treat that stuff as ours. So I want something that pulls in financial data read-only across accounts and gives us a shared view plus a shared agentic session. She has really taken to using ChatGPT, so the idea is being able to ask questions like “where is most of our spend going?” or “how do the investments look?” against a central brain that can actually see across everything. If I build it, it will be configurable -- bring your own provider, or run a local LLM if you would rather your financial data never leave the house. I have no idea what the right form factor is yet.

A voice companion for GitHub. This is the one I’m poking at most actively. I feel like the GitHub app should do this and probably will eventually, but it doesn’t today. A big chunk of how I get work done now is creating issues and assigning them to agents. What I want is a push-to-talk companion -- the same interaction model you get in ChatGPT -- that lets me navigate all of that by voice. “What new issues came in today?” I have automation that scans BrandGhost error logs and files issues automatically, so there’s usually something. “Give me more detail on issue 123.” “Cool, assign that to an agent.” And then later: “Check in on that agent session -- did the PR land? Did it add proper tests?” The goal is being able to have that conversation without reading code. Maybe the answer isn’t even a dedicated app -- maybe it’s just wiring an existing assistant to my repositories through an MCP server. I need to play with it. If it does end up being a mobile app, it goes on the app stores.

A photo recovery tool. I used to work in digital forensics, and I spent about a decade building tools for exactly this. Since leaving, people still occasionally come to me with “I think these files are deleted, can you help?” -- and the funny part is I no longer have access to any of the tooling I helped build. I know how to build it again. Is that market saturated? Absolutely. But I have example code, it solves a real problem people bring to me, and there is no reason it can’t live on a website for a couple bucks.

Websites for non-technical friends. This one isn’t a product, it’s a favor I keep repeating. I have a close friend in the trades doing drywall and restoration work who is reasonably technical but would never spend the time to learn web development. He would get real value out of a proper site. I did the same thing for my video editor when he started a business on the side -- he has been fantastic about turning videos around when I hand them over late, so building him a site was an easy yes. The key detail is that I structure them so the owner can maintain them: copy a config file into ChatGPT, ask for the change, paste it back, done. I might start advertising that.

Why I Trust Agents With Some Of This And Not All Of It

The voice companion idea probably sounds sketchy to some people. “You’re just going to let AI do your work?”

Sort of. Here’s the honest breakdown.

There is a category of work where I trust an agent to go end-to-end, and it’s not blind trust -- it’s because I have built a lot of guardrails. File-based instructions that encode how the codebase works. Roslyn analyzers that enforce naming, null checks, and log validation so bad patterns fail at compile time rather than in review. Scoped custom agents and skills in Copilot CLI so each task runs with a narrow, well-defined job. The gates are what make the trust reasonable.

Then there is the other end of the spectrum. Big feature work, architectural changes, large refactors -- I’m not handing those over and walking away. I will still assign them to an agent and let it crank, but my expectation is not that it gets it right. My expectation is that I learn something from watching how it approaches the problem.

Sometimes there are genuine gold nuggets in there. Other times I look at the approach and immediately think “oh, that’s definitely not what I want” -- and that’s still valuable, because I often didn’t have a strong opinion until I saw a concrete option. Getting to “no, not that” without spending my own hours on it is a legitimately good trade.

Yes, it costs tokens. Yes, it costs someone’s compute. But it didn’t cost my evening.

My Best Ideas Show Up When I Can’t Act On Them

I don’t know if this is universal, but it is extremely consistent for me: my best ideas arrive precisely when I am nowhere near a computer.

Not at my desk. Not in a planning session. Walking, driving, at the gym -- suddenly I know exactly how to solve the thing I was stuck on last week, or a feature idea shows up fully formed. And then by the time I’m back at a keyboard, it has faded into something much blurrier.

That is honestly a big part of why the voice companion idea appeals to me so much. Not just “assign this issue to an agent,” but being able to talk through a half-formed idea out loud, argue with it a bit, and then say “open a GitHub issue on this repo with what we just worked out.” I have done exactly that with ChatGPT before, and the friction of translating it into the real repo is the only annoying part left.

Actionable Tip: whatever your capture mechanism is, make it require zero setup. Voice memo, a note that’s one tap away, a text to yourself -- it doesn’t matter which. The ideas you lose aren’t the ones you rejected, they’re the ones you never wrote down.

Might As Well Turn The Fun Into Something

The through-line for me is that I am going to keep building this stuff regardless. That was true before there was any chance of making a dollar from it, and it will be true after.

But I’m at a point in my career and my life where if I’m already spending the time, and the thing I built is genuinely useful, it seems a little silly not to put it somewhere people can find it. Worst case, nobody buys it and I still have the tool. Best case, a few extra dollars show up and I get a nudge to actually finish the next one.

That’s the trade I’m making. Build for yourself first. Ship the smallest usable version. Let the thin paid layer be the reason you cross the finish line instead of drifting to the next shiny thing.

So -- what are you building? I’d genuinely like to hear, especially if you’re leaning on AI to crank out something interesting. Let me know.

Dev Leader Weekly

Discussion about this post

Ready for more?