Side Projects as Career Accelerators

Most of the career-defining skills I’ve picked up didn’t come from work. They came from things I built on nights and weekends.

This site, the one you’re reading right now, started as a side project. It’s been rebuilt twice, redesigned from scratch, and taught me more about frontend development, design systems, and content strategy than any task I was ever assigned at a job.

The agentic finance tool I wrote about? Side project. The experience rewriting a backend in Go? Started as a side project. The opinions I have about boring technology and AI product architecture? Formed through side projects where I had the freedom to experiment and fail.

Side projects aren’t extracurricular. For engineers, they’re the primary mechanism for growth that your day job can’t provide.

What Your Day Job Can’t Teach You

Your day job teaches you to work within constraints. That’s valuable, since real-world engineering is all about constraints. But those same constraints limit what you learn.

You can’t choose the stack. Your company uses Java and PostgreSQL. You want to learn Go, or Svelte, or a different database paradigm. Your job won’t let you experiment with production systems, and it shouldn’t.

You can’t own the full picture. In most engineering roles, you work on a slice of a larger system. You might never touch deployment, never make an architectural decision, never talk to a customer. Side projects force you to do all of it.

You can’t fail safely. At work, failure has consequences for your team, your users, your company. In a side project, failure is cheap. A bad architectural choice in a side project costs you a weekend. The same choice at work could cost months of refactoring.

You can’t follow your curiosity. Your job has priorities. You can’t drop everything to explore a new API, build a prototype for an idea, or deep-dive into a technology you’re curious about. Side projects are where curiosity gets to run.

The Skills Side Projects Build

End-to-End Ownership

In a side project, there’s no DevOps team to set up your pipeline, no designer to hand you mockups, no product manager to write requirements. You do everything: design the interface, write the code, set up the database, configure deployment, write the copy, fix the bugs.

This end-to-end ownership builds a mental model of how software systems actually work: not just the code layer, but the full stack from user experience to infrastructure. Engineers who have this full-picture understanding make better decisions in every role they take.

Decision-Making Under Uncertainty

At work, many decisions are made for you by the architecture, the team norms, or historical precedent. In a side project, every decision is yours. Which framework? Which database? Which hosting provider? How should the data model look?

You’ll make bad decisions. That’s the point. Making a bad decision, living with the consequences, and then understanding why it was bad is more educational than following someone else’s good decision.

Shipping Discipline

The hardest part of any side project isn’t starting it. It’s finishing it. The graveyard of unfinished side projects is enormous. But the ones you finish teach you something critical: how to cut scope, prioritize, and ship something imperfect.

This skill transfers directly to your professional work. The engineer who can ship a working feature this week beats the engineer who’s still perfecting it next month.

Communication

If you write about what you build, you’re practicing technical communication, a skill that’s at least as valuable as the coding itself. Blog posts, README files, and project documentation demonstrate your thinking to potential employers, collaborators, and clients far more effectively than a resume.

What Makes a Good Side Project

Not all side projects are created equal. The ones that accelerate your career share a few characteristics.

Scratch Your Own Itch

The best side projects solve a problem you actually have. This gives you two advantages: motivation (you care about the outcome) and domain knowledge (you understand the problem deeply).

I didn’t build a personal finance tool because I thought it would be a good resume project. I built it because I wanted a better way to manage my own finances. The fact that it turned into a compelling portfolio piece was a side effect of genuine engagement.

Choose One New Thing

A project that uses an entirely new stack (new language, new framework, new database, new deployment platform) is a recipe for burnout. You’ll spend more time fighting tooling than building features.

Instead, keep most of your stack familiar and introduce one new element. Building a web app? Use the framework you know, but try a new database. Know the backend well? Keep the backend boring and try a new frontend framework.

One new thing is enough to learn from. More than one is a liability.

Make It Public

Put it on GitHub. Deploy it somewhere. Write a blog post about it. A private side project on your laptop is a learning exercise. A public side project is a portfolio piece, a conversation starter, and evidence of competence.

You don’t need to market it or seek an audience. Just making it accessible is enough. When someone asks “have you worked with X?” you can point to a real, deployed project instead of saying “I read the docs once.”

Set a Deadline

Side projects without deadlines expand forever. Give yourself a constraint: “I’ll ship a working version by the end of the month.” The deadline forces you to cut scope, make decisions, and ship. Those are all skills you’re trying to develop.

The deadline can be arbitrary. A conference talk, a blog post, a personal milestone. What matters is that it creates pressure to finish.

Common Traps

The Tutorial Treadmill

Doing tutorials isn’t the same as building a side project. Tutorials are guided tours where someone else made all the decisions for you. When the tutorial ends, you haven’t practiced decision-making, scoping, or debugging your own problems.

Tutorials are great for initial exposure. But the learning happens when you close the tutorial and build something from scratch.

Scope Creep on Yourself

You start building a simple to-do app to learn a new framework. Two weeks later, you’re implementing real-time collaboration, a plugin system, and a custom query language. You’ve lost the thread.

Define the MVP before you start. Write down the three features that constitute “done.” Build those three features and ship. You can always add more later, but only after you’ve shipped the core.

Burnout

Side projects should be energizing, not exhausting. If you’re coding all day at work and then coding all evening on a side project, you’ll burn out. Protect your recovery time.

My approach: I work on side projects in focused sprints (a weekend here, an evening there), not as a daily obligation. Some weeks I don’t touch them at all. The project will still be there when I come back.

Perfection Paralysis

The project isn’t good enough to show anyone. The code isn’t clean enough. The design isn’t polished enough. So you keep refining and never ship.

Nobody expects a side project to be production-grade. Ship it rough. The fact that it exists and works is more impressive than a hypothetical perfect version that doesn’t.

How Side Projects Open Doors

Hiring Conversations

In interviews, side projects are gold. They give you concrete examples of decisions you’ve made, problems you’ve solved, and tradeoffs you’ve evaluated. “In this side project, I chose X because of Y, and I learned Z” is infinitely more compelling than “I’m a fast learner.”

Hiring managers, especially at smaller companies, pay attention to side projects because they show initiative and genuine interest in the craft.

Consulting and Freelance Work

My consulting work grew directly from side projects. Clients found me through this blog, which exists because I built it as a side project. The technical skills I demonstrate through my projects are what give clients confidence to hire me.

If you want to do freelance or consulting work, a portfolio of shipped side projects is your most effective marketing tool.

Conference Talks and Writing

Every blog post I’ve written about AI systems, tool-use patterns, or web development originated in a side project. The project gave me hands-on experience. The writing crystallized what I learned. The combination opened speaking and publishing opportunities.

Unexpected Opportunities

Side projects create serendipity. You never know who will see your work, what problem it will solve for someone, or what conversation it will start. The best opportunities I’ve had (projects, collaborations, jobs) came from someone finding a side project and reaching out.

You can’t plan serendipity. But you can increase its surface area by building in public.

Start This Weekend

You don’t need a groundbreaking idea. You don’t need a business plan. You need a problem you want to solve and a few hours to start solving it.

Here’s a formula that works:

Pick a problem you have: something annoying, inefficient, or missing from your life
Pick one new technology to learn: a framework, a language, a tool
Define three features that constitute “done”
Set a deadline: two weekends from now
Ship it. Deploy it, push it to GitHub, write about it

The project doesn’t need to be useful to anyone else. It doesn’t need to be impressive. It needs to be finished.

Every finished side project makes you a better engineer, builds your portfolio, and increases the chance that something good comes from it. The compounding starts with the first one.

Build something this weekend. You’ll be glad you did.