Make Time for a Side Project as a Developer

Why is scoping, not scheduling, the real problem?

If you can't find time for the side project, it's usually scoped too big, not your calendar too full. A project shaped like a funded startup — auth, billing, a dashboard, and a mobile app — needs a team's hours and quietly dies around month two. Cut it to the smallest thing a stranger could use once: one endpoint, one script, one page that does one job well. When the outcome fits inside a week's leftover hours, finding time stops being the bottleneck and the only question left is building.

Fight scope drift by writing the project's one-sentence job and refusing every feature that doesn't serve it. A CLI that renames files is a shippable project. That same CLI plus a config UI plus a plugin system is three abandoned projects. For a time-starved build, a tight scope is the feature, not the constraint: it's what lets you ship before your motivation, or your one free evening this week, runs out.

How many hours a week does a side project actually need?

There's no magic number, but the useful question is how your hours are shaped, not how many there are. Ten hours in one Saturday block behaves nothing like ten hours in twenty-minute scraps between standups. Match the project's session size to the time you can genuinely assemble, then scope to your row in the table below instead of the more ambitious row above it.

The goal isn't hitting an hour count; it's dropping the fiction that you have a founder's schedule. Pick the row that matches your life this quarter, scope honestly to it, and re-evaluate when the on-call rotation ends or the newborn finally sleeps through the night.

How do you cut the cold-start cost between sessions?

The gap between sessions is where solo projects leak the most time. You reopen the repo on Thursday, can't remember Tuesday's plan, and spend the first twenty minutes reconstructing your own head instead of writing code. Engineer the restart to be near-instant so a week of momentum survives instead of resetting to zero every time you sit down.

• →End every session by committing a failing test or a // NEXT: comment that names the exact next step, so future-you starts building, not deciding
• →Keep a one-command start — make dev or a single script that boots the whole stack — not a six-step README you have to reread each time
• →Maintain a running scratch file with the current decision and the open question, so you re-enter with context instead of re-deriving it
• →Build on a stack you already know cold; a side project with 5 hours a week is the wrong place to also learn a new framework
• →Automate the deploy down to one push, so shipping isn't an evening of yak-shaving you'll dread and quietly postpone

How do you protect building time around a job and on-call?

Put the blocks on the calendar as real events, not intentions, and score yourself on the ones you actually keep. Two protected 90-minute blocks you hit beat five you skip and feel guilty about. Anchor each block to something that already happens — right after the gym, before the house wakes up — so the trigger is automatic and you're not renegotiating with a tired version of yourself every night.

Guard energy, not just time. An hour after a day of incident response is worth a fraction of a fresh Saturday hour, so schedule the hard design thinking for your peak and leave the rote work — tests, refactors, documentation, copy — for the depleted slots. And keep the whole thing off your employer's laptop, repos, and accounts, so what you build stays unambiguously yours.

What should you build if the point is to own it?

Since the reason to spend scarce evenings is leverage, build something where your name is on the asset, not just your commits in someone else's repo. A small tool other developers pay a few dollars a month for, a content site that compounds while you sleep, a library that doubles as a public résumé — those accrue to you. Contributing to a trendy open-source project is good practice, but it builds the maintainer's leverage, not yours.

Owning it also bends the scope math in your favor. You don't need a polished product; you need one real user — possibly just yourself — with a problem you can actually solve in the hours you have. Validate that narrow slice before you spend a single evening on billing, scale, or a landing page. Scarce time is exactly what keeps you honest about building the smallest thing worth owning.