"Side project" sounds neutral. Descriptive. Just a label for work that happens outside the main thing.
It's not neutral. It's a ranking.
The term quietly sorts work into categories: real and extra. Paid and unpaid. Approved and optional. The "main" project is serious. The side project is hobbyist, experimental, not quite legitimate.
That hierarchy is false—and corrosive. Some of the most important work happens in the margins. Calling it a side project is a way of discounting it before it has a chance to count.
The Wrong Metric
The implicit logic is: if it doesn't pay, it's not real work.
But money is a lagging indicator, not a truth test. Plenty of paid work teaches you nothing transferable. Plenty of unpaid work builds skills you'll use for decades.
What actually counts is transfer:
- Did it force you to learn something reusable?
- Did it sharpen judgment, not just output?
- Did it ship, run, or survive contact with reality?
If yes, it counts—regardless of payroll.
This isn't a blanket defense of unpaid work. Most side projects don't matter. They're procrastination dressed as productivity, or identity performance, or sandboxes that never touch reality. The ones that count are the ones that force real learning, survive real constraints, and ship something that works. The bar isn't "I spent time on it." The bar is transfer.
A project that makes you more capable is real work. The invoice is irrelevant.
The Tool That Became Infrastructure
A few years ago, I started building browser tools and personal sites. No client. No deadline. No one asking for it.
From the outside, it looked optional. "Just websites." Something to do on the side.
What it actually forced me to learn:
- How to ship without permission or external pressure
- How to design systems that survive low motivation
- How to scope work so it actually finishes
- How to think in primitives instead of features
- How to own the full stack: idea → structure → execution → maintenance
I didn't just learn HTML or design. I learned how to build things that last without a boss or a sprint cycle. That skill shows up everywhere now—decision-making, writing, systems thinking, even how I evaluate jobs.
Some of those tools still run years later. Others taught me why they shouldn't have. Both kinds counted.
That wasn't a side project. That was infrastructure. I just didn't have a paycheck proving it.
The "Play" That Turned Foundational
Around the same time, I started writing down how I think. Frameworks for decisions. Patterns for recurring problems. Notes on what works and what doesn't.
From the outside: essays, notes, thinking out loud. No audience. No monetization. No obvious point.
What it actually built:
- A repeatable way to clarify decisions under pressure
- Language for diagnosing problems instead of reacting to them
- A personal operating system I now default to when things get hard
It looked like play because there was no boss, no deadline, no accountability. But it trained judgment—the hardest thing to outsource or fake.
That kind of learning almost never happens at work. Work optimizes for output, not for how you think. The "unserious" projects are often where the serious development happens.
The Embarrassing Contrast
Here's the uncomfortable part: most of my paid work taught me less than the unpaid stuff.
That's not an indictment of jobs. Jobs are good at what they're good at—paying bills, teaching local competence, exposing you to problems you wouldn't choose. But they're often bad at building transferable capability. The system optimizes for output, not growth.
Jobs taught me local knowledge. How this system works. How this process wants to be fed. How to avoid breaking something I don't own. Useful—but shallow. Non-transferable. Bound to a context that no longer exists.
The unpaid projects forced something harder:
- Define the problem yourself
- Decide what not to build
- Live with the consequences of bad decisions
- Maintain things when motivation disappears
That's real learning. And none of it came with a paycheck.
The "main" work paid the bills. The "side" work made me better. If I had to choose which mattered more for my actual capabilities, it's not close.
Why We Keep the Label
Calling something a side project is protective. It lowers expectations—yours and everyone else's.
If it's a side project, it doesn't have to be good. It doesn't have to ship. It doesn't have to mean anything. You're just tinkering.
That protection has a cost. It trains you to discount your own work. To preemptively dismiss the thing you're building before anyone else can. To treat your best learning as less legitimate because no one's paying for it.
The label isn't just inaccurate. It's a way of hiding from the fact that you're building something real.
The Reframe
You don't have side projects. You have projects.
Some pay immediately. Some pay later. Some pay in skill, leverage, or optionality that won't show up on a balance sheet for years. Money is one currency. Capability is another. The exchange rate varies, but both are real.
The ones that make you sharper, more capable, or harder to replace—those are often the ones that matter most. And they're often the ones without a client.
Stop ranking your work by who's paying for it. If a project teaches you something real, it's not a side project.
It's just unpaid—for now.