Quick answer: The day-job indie path works — most shipped indie games were made this way — but it runs on energy management, not time management: schedule dev for your good hours, scope to roughly half the weekly hours you think you have, and build systems (session notes, tiny tasks, weekly ships) that keep momentum through the bad weeks the job will cause.
The day-job indie path works — most shipped indie games were made this way — but it runs on energy management, not time management: schedule dev for your good hours, scope to roughly half the weekly hours you think you have, and build systems (session notes, tiny tasks, weekly ships) that keep momentum through the bad weeks the job will cause. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Budget energy, not just hours
Ten tired evening hours produce less than four fresh weekend-morning ones. Map your week honestly: when are you actually sharp? Protect those slots for hard problems (systems, debugging), and spend tired slots on low-cognition work — asset tweaks, playlist-style polishing, organizing. The schedule that works is the one aligned with your energy, not your calendar's empty spaces.
Defend the boundary in both directions: dev time isn't job-overflow time, and one protected no-game day per week is what keeps the other six wanting to happen.
Scope rules for part-time reality
The part-time multiplier is brutal: a '6-month full-time game' is a 2-3 year evenings game, and enthusiasm rarely survives year two of one project. Counter-scope accordingly: pick a game finishable in 6-12 part-time months, cut systems before content and content before polish, and prefer designs with repeatable loops over handcrafted-content treadmills.
Small shipped games compound — skills, audience, store presence, confidence. The three-year dream resumed later beats the three-year dream attempted first.
Momentum systems beat motivation
Cold starts are the part-timer's enemy: twenty minutes re-finding context eats a forty-minute session. The fixes are mechanical: end every session by writing the literal next action ('wire pause menu button'), keep tasks small enough to finish in one sitting, and maintain a visible done-list because part-time progress is invisible day-to-day and demoralizing without receipts.
Ship something on a cadence — a monthly build to friends, a devlog post — to create the external heartbeat a job's deadlines otherwise monopolize. Projects with heartbeats survive; projects without them quietly stop.
Momentum is a resource — budget it
Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.
When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.
Decide how you'll know it's working
Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.
This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.
The quiet work that protects all of this
Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.
Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Scope to the hours you really have, then ship the small game that fits them.