DEV Community

Cover image for What I Learned After Building Dozens of Side Projects (Mostly By Accident)
Christoffer Madsen
Christoffer Madsen

Posted on

What I Learned After Building Dozens of Side Projects (Mostly By Accident)

Over the past few years, I’ve built a surprising amount of projects. Not all of them shipped. Some turned into real tools people use. Some became prototypes. Some died halfway through because I lost interest. But I noticed certain patterns — lessons that kept repeating no matter what I was building.

These are the things I wish someone had told me much earlier.


1. Clarity beats cleverness

Almost every time I got stuck, the solution wasn't a new library or pattern. It was something much simpler:

  • Rename a confusing variable.
  • Write the UI state in one place instead of six.
  • Remove a layer of abstraction that didn’t help.
  • Make the flow explicit instead of “smart.”

Code that is easy to understand is code you actually want to work on.
If I avoid my own code, I know I tried too hard to be clever.


2. The right stack is the one you can keep momentum in

I’ve built projects in:

  • Next.js
  • Vite + React
  • Electron
  • Supabase
  • MySQL
  • Node APIs
  • Rust experiments

The takeaway wasn’t “use Stack X.”

It was:

Pick the stack that makes the next step easy.

If the framework gets in the way, it’s the wrong framework for this project, even if it’s technically “better.”

Momentum > purity.


3. A project only becomes clear when it has a real audience

Whenever I tried to build something “for everyone,” everything was foggy:

  • What features?
  • What UI?
  • What workflow?

But the moment I defined a real user — like a coworker, a partner, or a local business — the design decisions made themselves.

“Real person, real problem” is the fastest way to clarity.


4. Reusability is a quiet superpower

Over time, I realized I was slowly building a toolkit:

  • UI components I keep reusing
  • Tailwind + React project structure I always return to
  • A few motion patterns that feel like “my style”
  • A mental model of how I like routing and data flow

Each new project is now faster to start than the last.

That’s the long game.


5. When motivation drops, the scope is wrong

Every time I stalled, one of these was true:

  • The next task was too big
  • I didn’t know what exactly to do next
  • I wasn’t seeing progress visually
  • I was building something abstract instead of tangible

Once I sliced the work smaller, motivation came back.

Motivation isn’t magic. It’s feedback.


6. Shipping something imperfect is better than polishing something imaginary

This one took time to accept.

It’s better to release something small and real than to keep perfecting something that doesn’t exist yet.

Real things create momentum.
Unreleased things create stress.

Done is a feature.


7. The best workflow I’ve found is iterative conversation

My best projects followed a simple loop:

  1. Outline idea (imperfect is fine)
  2. Build a small working version
  3. See it on screen
  4. Adjust based on how it feels
  5. Repeat

Planning is useful, but only if you actually build in between.

Thinking and building need to happen in cycles, not phases.


Final Thought

If I had to sum all of this up:

Progress comes from clarity, constraints, reusability, real users, and shipping in small steps — not from chasing the perfect architecture.

Side projects aren’t just about building products.

They’re how you train your taste.

If you’re working on something now: make the next step small, visible, and real. Then take that step.


If you got something from this, I’d love to hear what you’re currently building.
Drop it in the comments — I’ll actually read it. 🙌

Top comments (1)

Collapse
 
a-k-0047 profile image
ak0047

Thanks for sharing your experience!
I'll keep these in mind.