How I Ship Side Projects Without Burning Out

Side projects are how I learn, but they're also how I burn out. After years of starting things and abandoning them three weeks in, I built a system that actually lets me finish.

Scope Like a Lazer

The number one reason side projects die is scope creep. "I'll just add auth. Oh, and notifications. Maybe a dark mode." Sound familiar?

The one-feature rule

Pick exactly one feature that, if it works, makes the project worth building. Everything else is a distraction until that one feature ships.

A project with one finished feature beats ten projects with ten half-built features every single time.

Timebox Everything

Set a hard deadline before you write a line of code. For side projects, I use these rough budgets:

• Weekend project: 2 days, one narrow feature.
• Month project: 4 weekends, an MVP you'd actually use.
• Quarter project: A real tool others could adopt.

// A real example from my project board
const projects = [
  { name: "shader-playground", budget: "1 weekend", shipped: true },
  { name: "kanban-board", budget: "1 month", shipped: true },
  { name: "the-perfect-app", budget: "forever", shipped: false }, // 👈
];

Notice the pattern: bounded projects ship. Open-ended ones don't.

Build in Public, but Quietly

Sharing progress creates gentle accountability. But avoid the dopamine trap of chasing likes instead of shipping features.

• Commit to one weekly update, not daily.
• Share what you learned, not just what you built.

Know When to Stop

Some projects teach you what you needed and then they're done — even if they never launch. That's a success, not a failure.

Summary

• Scope to one core feature.
• Timebox with a real deadline.
• Define done before you start.
• Accept that not every project needs to launch.

Ship something small this weekend. You'll be glad you did.