How to code on side projects after a full day of work

You get home from work. You ate dinner. You have maybe an hour before your brain shuts off. And somewhere on your laptop is a side project that needs those 45 minutes more than anything.

Most of the time, the side project loses. Not because you do not want to work on it, but because the activation energy is too high. You are tired. The context is gone. Opening VS Code feels like a commitment you cannot afford.

This is the central problem of coding side projects with a full time job: you are not short on ambition. You are short on usable energy. And the usual productivity advice, “just wake up at 5am,” “block out your calendar,” does not account for the fact that your brain has been problem-solving all day.

Here is how to code after work without burnout, based on what actually works.

Accept the constraint instead of fighting it

The first step is being honest about how much time and energy you realistically have. For most people with a day job, that is 30 to 90 minutes on a weekday evening. Sometimes less. Rarely more.

Once you accept this, you stop trying to have marathon sessions and start optimizing for short ones. The real question behind developer side project time management is not “How do I find more time?” but “How do I make 45 minutes count?”

This is a fundamentally different design problem. And it changes everything about how you approach evening coding productivity.

Reduce startup cost to near zero

The biggest enemy of a short session is startup time. If it takes you 15 minutes to remember what you were doing, and you only have 45 minutes total, you have already lost a third of your productive window.

This is the 15-minute window problem we wrote about in our post on context debt. The reload cost eats the session.

The fix is to eliminate the reload entirely. At the end of every session, spend 60 seconds writing a note to yourself: what you were doing, what file you were in, what the next step is. Be specific. “Continue implementing the refresh logic in auth.ts, the failing test is token-refresh.test.ts line 34” is infinitely better than “work on auth.”

This is what KeepGoing is built for. It captures your context at the end of a session and puts it in front of you at the start of the next one. The goal is to make opening your project feel like hitting unpause instead of starting cold.

Work in atomic steps

When your sessions are short, you need to think in smaller units. Not “build the user profile page” but “add the avatar component” or “wire up the name field to the API.”

Each unit should be completable in a single session. Ideally, you should be able to commit something at the end of every session, no matter how small. This creates a sense of progress that compounds over time, even when each individual session feels tiny.

The alternative, a feature that spans five sessions, creates a long stretch where nothing is “done.” And during that stretch, motivation erodes because you cannot see forward movement.

Small commits, small PRs, small wins. They add up faster than you think.

Protect your energy, not just your time

Time management is not enough. You also need energy management.

Coding after eight hours of knowledge work is not the same as coding fresh in the morning. Your decision-making capacity is lower. Your tolerance for debugging is lower. Your creativity may be intact, but your patience is not.

This means you need to be strategic about what you do in evening sessions:

Save creative work for weekends. Architecture decisions, new features, design explorations: these need a fresh brain. Do not try to make big decisions at 9pm.
Evenings are for execution. Pick up a well-defined task with a clear outcome. Implement the function. Fix the bug. Write the test. Things where the thinking is already done and you just need to type.
Prep tasks in advance. Before you close your laptop at work, spend two minutes thinking about what you will work on tonight. Not working on it. Just deciding. This removes the “what should I do?” decision from the evening, when your willpower is lowest.

The “one small step” rule

On the days where you have almost no energy, the temptation is to skip entirely. And sometimes skipping is the right call. Rest matters.

But on the days where you could go either way, try this: commit to doing just one small thing. Open the project, make one change, and commit it. That is it. You have permission to stop after that.

What usually happens is that the hardest part was starting. Once you are in, the context loads, and you end up doing more than you planned. But even if you do not, you made progress. And you kept the project warm, which means tomorrow’s session will start faster.

This is the opposite of the marathon mindset. It is a practice of consistent, tiny contact with the project. Over weeks, those tiny sessions accumulate into real features.

Do not sacrifice sleep or health

This should go without saying, but: a side project is not worth your health. If you are staying up until 1am to code and dragging through your day job, the math is working against you. You will burn out, and the project will die anyway.

The sustainable approach is to treat side project time as a bonus, not an obligation. Some weeks you will get five sessions in. Some weeks zero. Both are fine. What kills projects is not the occasional missed week. It is the accumulated context debt from not having a system to pick back up.

Build the system. Then use whatever time you have.

You do not need more hours. You need less friction.