I'm a software developer. Monday to Friday, 9 to 5, I work in a corporate environment — sprints, code reviews, Jira tickets, the whole thing. It's good work. Serious work. The kind where you do one thing well and the team around you does the rest.
Then I close my laptop at 5 and I open it again an hour later to work on my own stuff.
That's the part where things get complicated — because side projects don't come with a team.
The Problem Nobody Talks About
There's a version of side project advice that sounds like this: "You just need discipline. Wake up early. Grind on weekends." And sure, that works if your project is a blog or a simple landing page. But what if you want to build something real? A SaaS. A tool with a proper backend. A product you'd actually charge money for?
That's where solo developers hit a wall — not because they lack skill, but because they lack bandwidth. During my work hours, I'm a developer. But my project also needs someone to design the UX, write the copy, configure the infrastructure, manage the database schema, review the security, think about the business logic, and do the dozen other things that a proper team would normally split between five or six people.
My side projects were always stuck between two versions of themselves: too ambitious to finish alone, too personal to hand off.
I didn't want to simplify my projects to the point where they stopped being interesting. I wanted to build things that actually worked, end to end. I just didn't have twenty hours a week to get there.
Why I Vibe Code My Side Projects (And Not My Day Job)
Let me be clear about something first: I don't vibe code at work. At work, I write code the way my team writes code — methodically, with reviews, with tests, with all the craft and discipline that a professional codebase demands. That rigor matters and I respect it.
But side projects are a different equation. The constraint isn't quality — it's time. And when time is the constraint, the question isn't "what's the most elegant way to build this?" It's "how do I go from idea to working product without the next six months slipping away from me?"
That's the answer to why I vibe code my side projects. Not because I'm cutting corners on craft. Because AI now lets me do in two hours what used to take two weekends — and it handles the parts I'd otherwise never get to at all.
I'm not replacing engineers with AI. I'm replacing a squad that was never going to exist in the first place.
What My Side Project Stack Actually Looks Like
Here's the thing that might surprise you: my workflow doesn't look that different from work. Same tools, same habits — just a different team doing the heavy lifting.
- Visual Studio Code. Same editor I use all day. No context switching, no learning curve, no new environment to configure. I open the same app I had open five minutes ago and start building.
- GitHub. Because version control is non-negotiable, even when you're a team of one. Especially when you're a team of one — there's no one else to bail you out when something breaks.
- Claude Code. The engine behind everything. Claude Code lives inside VS Code, reads my entire codebase, and operates like an agent — not just answering questions but actually writing, editing, refactoring, and running commands. This is the part of my stack that changes the math on what's possible in an evening.
- Netlify (free tier). Deployment without an ops team. I push to GitHub, it deploys. That's the whole workflow. No servers to manage, no configuration nightmares, no bill to justify.
- Supabase (free tier). A proper PostgreSQL backend with auth, real-time subscriptions, and a reasonable API — without the overhead of setting up and maintaining an actual database server. At work I deal with SQL Developer and all the ceremony that comes with it. At home, Supabase gives me the same power with a fraction of the friction.
The through-line is that this stack is deliberately free, deliberately familiar, and deliberately designed to minimize the parts of a project that aren't building. I'm not interested in spending my evenings configuring infrastructure. I want to build features.
What AI Actually Does in This Stack
Claude Code isn't just a fancy autocomplete. In my side project workflow, it plays roles that would normally require separate humans.
When I'm starting something new, I'll describe the idea in plain language — the problem I'm solving, the kind of user I'm targeting, the general shape of the product — and Claude Code helps me translate that into a working file structure, a database schema, and an initial implementation. That's the architect role.
When I'm in the middle of building, it's writing the boilerplate I'd otherwise spend an hour on, catching bugs I'd otherwise spend another hour hunting, and suggesting edge cases I'd otherwise discover at 11pm when something breaks in production. That's the senior developer role.
And when I'm shipping, it helps me write the copy, think through the UX flows, and make sure the security basics aren't embarrassing. That's everything else the squad does.
I'm not an AI doing vibe coding. I'm a developer using AI to finally have the team my side projects always deserved.
I stay in control of every decision that actually matters — the product direction, the architecture choices, the things that determine whether this project is worth building at all. I just stopped pretending I had to do the implementation alone.
Side Projects Make You Better at Your Day Job
This part took me by surprise, but it's true: working on side projects has made me meaningfully better at my corporate work. Not in a vague "it builds character" way. In specific, practical ways.
When you own an entire stack end to end — frontend, backend, database, deployment — you develop an intuition for how things connect that you don't get from working on one layer in isolation. I've come back to work on Monday with a clearer mental model of a system we were building because I'd spent Sunday debugging the same pattern in my own project.
Side projects also force you to think like a product owner, not just a developer. When there's no PM to hand you a spec, you have to figure out what the right thing to build actually is. That muscle — deciding what matters and what doesn't — makes you more valuable in a team setting, where those decisions happen constantly and someone has to have an opinion.
And the AI skills transfer too. Learning how to prompt well, how to structure a task for an agent, how to review AI output critically — these are becoming real professional skills. The developers who are ahead of that curve at work are often the ones who've been practicing it on their own time.
Choosing the Right AI for Your Side Projects
Not every AI is the same, and not every side project has the same needs. Claude Code is my main tool because it's deeply integrated with VS Code, it handles complex multi-file tasks well, and it operates as a true agent rather than just a chat interface. For serious coding work, it's my recommendation without hesitation — and if you want the full breakdown of how to use it well, I wrote about it in detail in Vibe Coding in 2026: The Complete Guide to Claude Code in VS Code.
But Claude Code isn't the only option worth knowing. I also use Grok, Gemini, and ChatGPT depending on what I need. Quick questions, fast lookups, brainstorming a product name — there are moments where a lighter tool is genuinely the right call. The mistake isn't using multiple AIs. The mistake is using the wrong one for the wrong job.
The best way to figure out which AI fits your workflow is to be honest about what you're actually building, how you work, and where you're losing the most time. The right answer is different for someone building a complex SaaS than for someone polishing a portfolio site.
What I'd Tell Any Developer Sitting on a Side Project Idea
If you have an idea that's been living in a notes app or a whiteboard for months because you "don't have time" — I understand that feeling completely. It's real. A full-time job leaves you with less than you think, and side projects can feel like a punishment if you approach them the same way you approach work.
But the calculus has genuinely changed. With the right AI tool and a stack that doesn't fight you, the gap between "idea" and "working product" is smaller than it's ever been. The craftsmanship is still there — you still have to make the real decisions, review what gets built, and take responsibility for what ships. The difference is that you're not doing it alone anymore, even when you're working solo.
Start something. Use the AI that fits your needs. Build the thing you've been putting off. Your day job will be better for it — and so will you.