What I Learned Shipping 10 Side Projects

I've shipped over ten side projects in the past decade. Some made money. Some taught me something. Most did both, just not in the proportions I expected.

This isn't a greatest-hits reel. It's the patterns I noticed after building Videolectures.net, co-organizing TEDxLjubljana, running Avant2Go (an all-electric carsharing service), launching a silver investment blog, building an AI content pipeline, and a handful of other things that lived somewhere between "weekend hack" and "actual company."

Here are the side-project lessons that stuck.

1. Ship the ugly version first

My first side project took six months to launch because I kept redesigning the landing page. The second one shipped in a weekend with a form and a Stripe checkout. Guess which one made money?

The ugly version teaches you things the polished version never will. You learn whether anyone actually wants what you're building. You learn what breaks when real people use it. You learn that your assumptions about the user flow were wrong in ways you couldn't have predicted from Figma.

I now have a rule: if the first version doesn't embarrass me a little, I waited too long.

2. Side projects die from neglect, not from competition

I've never had a side project fail because a competitor outbuilt me. Every single one that died, died because I stopped showing up. Life got busy. The day job demanded more. A newer, shinier idea appeared.

The projects that survived had one thing in common: I built systems that kept them running without daily attention. Automated deployments. Scheduled content. Monitoring that pinged me only when something broke. For my blogs, that meant a content pipeline that could run without me touching it for weeks.

3. You don't need a co-founder. You need a forcing function.

Everyone told me I needed a co-founder for accountability. What actually worked was a public deadline. Telling someone "I'll show you this on Friday" did more for my productivity than months of solo planning.

For nakupsrebra.com, my silver investment blog, the forcing function was a content calendar. Two articles per week, published on schedule. No negotiation with myself about whether I "felt inspired." The calendar didn't care about my feelings. And the readers who subscribed to updates didn't care either.

TEDxLjubljana had an even simpler forcing function: a venue was booked and speakers were confirmed. You can't postpone a live event because you're not "ready."

4. Solve your own problems first

Every successful side project I've built started as a solution to my own problem. Avant2Go started because I was frustrated with car ownership in a city where parking alone costs more than a gym membership. The silver blog started because I couldn't find straightforward investment information in Slovenian. Everything was either in English or written by someone trying to sell me a product. The AI content pipeline started because writing, editing, and publishing manually was eating 15 hours a week.

The projects I built for hypothetical users? They went nowhere. I didn't care enough about problems I'd never experienced.

5. Revenue on day one changes everything

I used to think monetization was something you figure out "later." Then I launched a project with a paid tier from day one and everything changed.

Even if it's five euros per month. Even if only three people pay. Revenue creates accountability. It turns a hobby into a commitment. Someone gave you money. Now you owe them something. That feeling is more motivating than any todo list.

The side projects I monetized early survived. The ones where I planned to "add payments eventually" became portfolio pieces at best.

6. AI changed the math on what one person can build

I wish someone had told me this three years ago. A single developer with AI tools can now ship what used to need a small team.

I run a content pipeline with AI agents that handle research, writing, editing, design, and publishing. The whole system costs about €150 per month in API calls and infrastructure. Two years ago, that pipeline would have required three part-time contractors at minimum.

But here's the catch: AI doesn't eliminate work. It shifts it. Instead of writing articles, I'm writing prompts, building review systems, and debugging agent failures at 2 AM. The work is different, not less. Sometimes it's more. I wrote about this in detail in my post about the real cost of running AI agents.

Paul Ford recently wrote in the New York Times that work he used to charge $350,000 for is now a weekend project. I think that's directionally right, but it misses the debugging tax. The agents are fast until they're wrong. Then you're back to doing the work yourself, plus cleaning up theirs.

7. Every side project is a skills accelerator

My day job is managing an EV carsharing fleet. But the side projects taught me things the day job never would have: SEO, content marketing, API integrations, payment processing, DNS configuration, server management, prompt engineering.

These skills compound. By project number seven, I could spin up a new thing in a weekend because I'd already solved most of the infrastructure problems before.

8. Kill projects on purpose

I have a graveyard of side projects. Some I killed intentionally. Some I should have killed sooner.

The hardest lesson: stopping a project that "almost works" isn't failure. It's resource allocation. Every hour spent on a zombie project is an hour stolen from something with actual potential.

I now do a quarterly review. Each side project gets three questions: Is this making money or learning? Would I start this today with what I know now? Am I excited to work on this next weekend? Two "no" answers and it goes to the archive.

9. Your stack doesn't matter. Your shipping speed does.

I've built side projects in PHP, Python, Node.js, Next.js, plain HTML, and whatever framework was trendy that month. The technology choice has never been the reason a project succeeded or failed.

What mattered was how fast I could go from idea to something a user could touch. Pick the stack you can move fastest in. For me right now, that's Next.js and Vercel for web apps, with Claude handling the heavy lifting on content and code.

10. The compound effect is real but slow

Project one was painful. Slow. Everything was new. Project five felt easier because I reused infrastructure, patterns, and even code from the previous four. By project ten, I had templates, deployment scripts, domain management flows, and a content pipeline that worked across multiple blogs.

But this compounding only works if you pay attention to it. After each project, I spend a day documenting what worked, what broke, and what I'd reuse. That documentation is the compound interest. The project itself is just the deposit.

The real lesson

The biggest thing ten side projects taught me isn't a tactic. It's an identity shift.

When you're someone who ships, you make different decisions. You cut scope instead of adding features. You launch before you're ready. You kill things that aren't working instead of letting them linger on your todo list. At some point, the pattern becomes who you are rather than what you do.

Shipping is a muscle. The first time is terrifying. By the tenth time, it's Tuesday.