Shipping Side Projects While Employed — Without Burning Out

The honest framing

Every "I built this in two weekends" thread on the timeline is a compressed story. You don't see the four months of thinking in the shower, the abandoned first draft, the Saturday they lost to a deploy that wouldn't work. Shipping software on the side while you write software for a living is a real thing, and it's genuinely hard, and the only way to do it sustainably is to throw out the sprint mental model.

This is what's worked for me across maybe a dozen shipped side projects and a lot more unshipped ones. Your mileage will vary, but the shape is portable.

Calendar, not deadline

The failure mode that kills most side projects is the deadline. You set "ship by end of month", miss it because work got busy, and the project dies of guilt. The fix is to think in terms of a recurring slot, not a target date.

I book two hours on Tuesday and two hours on Saturday. That's it. The bar for "progress" within those two hours is comically low — even fixing a typo counts. The project lives as long as the slot stays booked. Projects die when the slot dies, not when a deadline slips.

The hidden benefit: because the slot is short, you're forced to leave the project in a runnable state every time. You can't afford a half-finished refactor across a one-week gap, so you get good at vertical slices. Which is, incidentally, how you should be shipping at work too.

Scope, the only lever

Side projects don't fail on talent. They fail on scope. The version of your idea that ships is roughly 10% of the version in your head, and getting comfortable with that number is the entire game.

A trick that's worked for me three times: write the launch tweet first. Describe what the thing does, who it's for, and what's interesting about it. Whatever fits in 280 characters is the project. Everything else is v2. You don't have a v2. You will be tired of this v1 by Friday.

On energy, not time

The cheap advice is "find the time". The real advice is "find the energy". Two hours when you're exhausted from a sprint review produces worse than zero net work, because you'll also have lost the evening. Notice which days your brain has leftover cycles and protect them. For me that's Tuesday mornings, before the work backdrop eats the context window. Saturdays only if the week was clean.

This is also why the slot model beats the sprint model: it's easier to cancel a two-hour slot than to recover from a burned Saturday.

The weekend sprint trap

The pattern I see over and over: someone gets a free Saturday, sprints for ten hours, ships a demo, and then doesn't touch the project for six weeks. The demo looks impressive in the moment, but momentum is set by frequency, not by peak hours. A Project touched for two hours every Tuesday for a year is twelve months of compounding; a project sprinted for ten hours once is a cool screenshot.

The corollary: don't trust a streak that you can only maintain under adrenaline. If you can only work on the thing when the mood is perfect, the thing won't ship. Build the slot. Lower the bar. Keep the slot.

When to actually ship

The last 10% takes the other 90% of the time, and side projects are where this rule bites hardest because you're doing it on leftover cycles. My rule: the moment the project is doing one useful thing for one real user (not you, not your friend), ship it. Then use the slot to make it less embarrassing. The version that went out the door is always bad. The version you can't ship because it's not finished doesn't exist.