The 10-Minute Planning Session That Keeps My Side Projects Alive

Side Projects Don’t Die From Lack of Time

They die from lack of direction. You sit down on a Saturday morning with two free hours, open your editor, stare at the codebase, and think: “Where was I? What was I doing? What should I work on?” Twenty minutes of context-switching later, you pick something semi-random, make partial progress, and close your laptop feeling like you wasted the session.

I’ve killed at least a dozen side projects this way. Not because I ran out of motivation, but because every session started with friction.

The fix is embarrassingly simple: a 10-minute planning ritual before you touch any code.

The Five Steps

Step 1: Read Your Last Session Notes (2 minutes)

Before your previous session ended, you wrote a few sentences about where you left off. Read them now. This is the single biggest time saver. Without it, you’ll spend 15 minutes re-discovering what past-you already knew.

If you didn’t leave notes last time, spend these 2 minutes scanning your recent git commits or open files to rebuild context.

Step 2: Pick the One Thing You’ll Ship Today (1 minute)

Not three things. One. The temptation with side projects is to jump between features because everything feels equally important. Resist that. Pick the smallest thing that moves the project forward in a visible way. “Get the login page working” beats “refactor the auth module” every time.

Step 3: Write Down What “Done” Looks Like (2 minutes)

This is the step most people skip, and it’s the most important one. Write one to three sentences describing what the finished state looks like. “Done means: a user can type their email, click submit, and see a confirmation message. No styling needed yet.”

Without this, you’ll gold-plate. You’ll rabbit-hole into edge cases. You’ll end the session with something 80% complete instead of something 100% shipped.

Step 4: List Your Blockers (2 minutes)

Write down anything that might stop you. “I need to figure out how to send emails from Next.js.” “I’m not sure how the database schema should work for this.” If a blocker looks like it’ll take more than 20 minutes to resolve, that’s a signal: either pick a different task for today, or timebox the blocker research.

Step 5: Set a Timer and Go (3 minutes)

Set a timer for your available coding time. Not because you need pressure, but because the timer makes the session feel finite and real. You’re not “working on the side project.” You’re doing a specific thing in a specific timeframe.

Why This Works

The entire ritual takes 10 minutes. But it converts a vague “I should work on my project” session into a focused sprint with a clear goal.

I’ve shipped more in 2 hours a week with this system than I used to ship in 8 hours of unfocused weekend coding. The secret isn’t working more. It’s removing the decision-making overhead that eats your limited time.

One more thing: at the end of each session, spend 2 minutes writing notes for next time. What you finished, where you stopped, what’s next. Your future self will thank you.