I’ve shipped four side projects in the last two years. None of them make money. All of them made me better at my job.
The side project paradox
The best way to get better at building products is to build products. But at work, you’re constrained -by deadlines, by existing architecture, by decisions made before you joined.
Side projects remove those constraints. You choose the stack. You choose the scope. You choose when to ship and when to throw everything away and start over.
What I’ve learned from each project
Riffims taught me how to think about mobile-first design not as a responsive technique, but as a product constraint. When the primary interaction is a thumb on a small screen, every pixel matters differently.
Linkims taught me about theming at scale. Building a system where every profile looks different but every profile is maintainable required me to think about tokens and variables in ways I never had before.
Prelude Icons taught me about the handoff between design and code. When an icon works in Figma but breaks in SVG, the problem is almost always in how the paths were constructed -not in how the code renders them.
The permission to experiment
At work, experimenting is risky. You’re spending the company’s time and the team’s goodwill. On a side project, experimenting is the point.
I’ve tried GSAP animations that would have been too ambitious for a production app. I’ve built component architectures that turned out to be over-engineered. I’ve written CSS that only worked in one browser.
Every failure taught me where the boundaries are.
Starting small
You don’t need a big idea. You need a small one that you care enough about to finish.
Build a link-in-bio page. Build a timer app. Build a portfolio.
The project itself doesn’t matter. What matters is that you chose every piece of it, and you understand why.