The Engineering and Leadership Lessons You Can Learn from Side Projects

I’ve been writing software for as long as I can remember. Long before I studied Computer Science in high school and college, I had side projects—things that pushed me to learn new languages, frameworks, and infrastructure. That drive to build something for myself, independent of school or work, shaped the way I approach software today.

Every side project, whether it went anywhere or not, taught me something. The experience of solving real problems, outside the structure of a job, has always been more valuable to me than any class or book. Looking back, there are clear lessons that side projects have taught me—lessons that have made me a better engineer and a better leader.

Building for Sustainability, Not Just Survival

One of those projects, Limited Run, started more than 15 years ago. For the first year, I built it outside of my full-time job—every night, every weekend. Then it turned into a business, and for years, it was my entire life.

I don’t recommend working 12–14 hour days, 7 days a week, for years. But at the time, it consumed everything. As a two-person company, I was responsible for building and running the software entirely on my own. The stakes got higher as we had to support massive artists—Billie Eilish, Beyoncé (during her Super Bowl halftime show and album launch), and others. It was surreal, especially considering that Limited Run started as a way to help small punk bands I actually knew.

Eventually, I was able to pull back. The systems I built, the design principles I followed—making everything as self-serve and automated as possible—meant that Limited Run no longer needed me in the same all-consuming way. This taught me a key lesson: when you’re building something alone, design for sustainability, not just survival. Leaning into the fact that it was all on me forced me to automate, simplify, and build systems that could run with minimal intervention. That approach shapes everything I build on my own today and gives me valuable experience I can draw from in my day job when it makes sense.

Staying Hands-On to Be a Better Leader

Fast forward to today, Limited Run is still running, still making money, but my approach to side projects has changed. I’m now a Director of Engineering at Recharge, leading multiple teams. My day job is no longer about writing software—it’s about supporting the people who do. But my experience building and running software on my own still influences my work every day.

At Recharge, I spend my time reviewing designs, asking the right questions, and helping my teams navigate complex decisions. Because I still build things outside of work, I can challenge assumptions and spot risks in ways that wouldn’t be possible otherwise. I know what it’s like to scale a system, to deal with outages at 3 AM, to make trade-offs between speed and maintainability. That hands-on experience builds trust—people can see that I understand the problems they’re facing, not just from a leadership perspective but from a technical one.

Meanwhile, my side project Looping brings me back to something much closer to Limited Run—a product built with the expectation that it needs to be rock solid, run by a single person, and require minimal customer support. But more than anything, it scratches the itch to write software. Staying hands-on with real projects makes me a better leader because it keeps my engineering instincts sharp and my problem-solving skills fresh.

Side Projects as a Training Ground for Better Decision-Making

I’ve been working on Looping for years—before I even knew if it could become a product. At first, it was just an idea: design docs, research, experimenting with different frameworks like Vue, testing architectural patterns like service objects with monad responses. Even if it never launched, it still would have been worth the time.

Because that’s the real value of side projects. They are a low-stakes way to practice decision-making. Every problem you solve refines how you think about software. Every new constraint forces you to adapt. What libraries should I use? What trade-offs should I accept? How do I structure this to be maintainable over time? The best ideas evolve, and some never turn into anything—but they still change the way you approach your work.

The Value in Doing

I don’t work on side projects to chase a startup dream or because I think they’ll turn into something huge. I do it because I love building things. Because it gives me an outlet for exploring ideas without the constraints of a roadmap or team priorities. Because it’s a space where I can work entirely for myself—and that, on its own, is worth it.

But more than that, side projects have been some of the best learning experiences of my career. They’ve taught me how to build for sustainability, how to stay hands-on as a leader, and how to make better engineering decisions. The next time you revisit an old side project or start a new one, don’t just focus on what you’re building—pay attention to what it’s teaching you.