Key Takeaway
Side projects survive full-time work not through motivation but through structure: cap scope to what 5-10 protected hours a week can ship, write a one-paragraph project brief defining what is explicitly excluded, and record end-of-session notes so context isn't rebuilt from scratch. Shipping a small, finished project beats abandoning an ambitious one.
Every developer wants to work on side projects. Most side projects die within 3 weeks. The gap between the idea and the shipped product is where ambition collides with the reality of having a full-time job (or degree), a life, and limited energy. At the time of writing, I had a specific version of this challenge: I was finishing a degree at SGU while working part-time, which left genuinely limited hours for personal projects. Over the previous year I'd developed — through trial and error — a set of principles for keeping side projects alive and occasionally shipping them. Here they are.
Why Most Side Projects Die: The Honest Diagnosis
Side projects don't die from lack of ideas or technical inability. They die from: scope that expands beyond what part-time effort can deliver; loss of motivation after the exciting initial phase; perfectionism that prevents shipping anything less than ideal; and the inability to maintain context across sporadic work sessions. The first two weeks of a side project are easy — the idea is fresh, the architecture decisions are interesting, and you're building core functionality. Then you hit the boring middle: form validation, error handling, documentation, deployment configuration, email templates. This is where projects die. The developer adds 'nice to have' features instead of shipping what exists.
The Scope Discipline Principle
The most important rule for side projects under time constraint: every feature idea goes on a list, and nothing from that list enters the current scope unless something else leaves it. The current version has exactly the features needed to be useful to one real user. No more. The Minimum Viable Product isn't a starting point — it's the entire first version. I've shipped things that felt embarrassingly simple that turned out to be exactly what users wanted. I've also abandoned projects that grew to elaborate specs that were never shipped. Simple and shipped beats complex and abandoned, every time.
Time Budget for Side Projects
Given a full-time work and study commitment, a realistic side project time budget is 5–10 hours per week — no more. This needs to be explicitly scheduled, not 'whatever's left'. I use weekend mornings (6–9am before family obligations start) and one or two weekday evenings (7–9pm). The key insight: 5 hours per week compounds significantly over 6 months (about 130 hours of focused work). A simple but polished web application can be built, tested, and deployed in 100–150 hours. The math works if you protect the time and don't scope-creep the project.
Side Project Time Math (part-time dev + full-time student)
──────────────────────────────────────────────────────────
Available hours/week: ~8–10 hrs (protected weekend mornings)
Hours over 6 months: ~130–160 hrs of focused work
What 130 focused hours can produce:
- Simple but polished SaaS MVP
- Production-quality portfolio app (deployed, CI/CD, docs)
- Open source library with tests and README
- Technical blog (12–15 well-researched posts)
Rule: 5 hrs/week compounding beats 30 hrs one weekend then nothing
Session structure (2-hour blocks):
0:00–0:05 Read end-of-last-session notes
0:05–1:45 Focused implementation (no context switching)
1:45–1:55 Write end-of-session notes (plain English)
1:55–2:00 Commit, push, close laptop
──────────────────────────────────────────────────────────Write a 'project brief' before starting any side project: one paragraph describing what it does, who it's for, what the success metric is (users, revenue, or just a portfolio piece), and what the first version explicitly does NOT include. Read this brief at the start of every work session. This prevents the gradual scope drift that kills projects and helps you make quick 'in scope / out of scope' decisions when new feature ideas emerge during development.
Context Preservation: The Real Problem With Sporadic Work
The biggest productivity killer for part-time side projects isn't time — it's context switching cost. Coming back to a project after 3–4 days away means spending the first 20–30 minutes remembering where you left off, what the current state of the code is, and what the next step is. This overhead, multiplied across every session, can consume 30–40% of your effective project time. The solution: write end-of-session notes (not code comments — plain English notes like 'I was trying to fix X, hit error Y, next step is Z'). I keep a scratch markdown file per project for these notes. The 5 minutes spent writing them saves 25 minutes of disorientation at the start of the next session.
Technology Choices for Side Projects Under Time Constraint
When time is limited, use boring, familiar technology for side projects. The side project is for shipping, not for learning a new framework. Save new technology experiments for throwaway prototypes, not projects you intend to ship. I use my work stack (Next.js + TypeScript + PostgreSQL) for personal projects because I work in it daily and have zero ramp-up time. The only exception: if the entire purpose of the project is to learn a specific technology — in which case, explicitly time-box it and don't attach shipping expectations.
# Project Brief Template (fill before writing a single line of code)
PROJECT_BRIEF = """
Name: [Project name]
What: [One sentence — what does it do?]
Who: [Specific target user — not "everyone"]
Goal: [Portfolio piece | Real product | Learning experiment]
Success: [Metric: deployed URL | 10 users | learned X tech]
Version 1.0 INCLUDES:
- [Feature A — must have]
- [Feature B — must have]
- [Feature C — nice to have, included if time allows]
Version 1.0 DOES NOT INCLUDE:
- [Feature D — backlog]
- [Feature E — v2]
- [Feature F — maybe never]
Tech: [Use boring familiar stack — no framework experiments]
Deadline: [Specific date — 6 weeks from today]
Kill condition: [If not shipped by X date, project is archived]
"""
# Read this at the start of every session.
# Add new ideas to the "does not include" list, not to scope.
What I've Actually Shipped and What I Haven't
Honest accounting: projects I've shipped or meaningfully contributed to: this portfolio site (deployed, internationalized, ongoing); blog posts documenting technical topics (ongoing); small utilities and scripts shared on GitHub. Projects I've started and not shipped: two SaaS ideas that grew beyond part-time scope; a mobile app prototype that got blocked on design decisions; a personal finance tracker that got replaced by a free app. The pattern in my failures is consistent: scope exceeded available time, or I tried to polish to 100% instead of shipping at 80%. The pattern in my successes: tight scope, familiar tech, personal need driving it (I built things I personally needed, not imagined needs).
The most insidious side project failure mode is a project that starts to succeed and grows beyond what part-time effort can sustain. Users appear, feature requests come in, bugs need fixing on timelines that feel like obligations. If you have a full-time job, this creates a second job dynamic that will eventually break one of the two commitments. Have a plan before this happens: either the side project becomes your primary focus (you reduce or quit the day job), or you explicitly limit its scope to what part-time maintenance can handle. Building something that requires your full-time attention while you have a full-time job will end badly.
The Portfolio Project vs. The Real Product: Different Goals
Clarify your goal before starting: are you building a portfolio piece (to demonstrate skills to employers) or a real product (to acquire users and potentially earn revenue)? These are different projects with different success criteria. Portfolio pieces need to demonstrate technical skill, clean code, and interesting architecture — they don't need users. Real products need to solve a real problem for a real person — they don't need to be technically impressive. Confusing these goals leads to portfolio pieces with unnecessary complexity and real products with premature optimization. Know which you're building.
When to Kill a Side Project
Knowing when to kill a project is as important as knowing when to start one. Signs a side project should be killed or paused: you haven't worked on it in 3+ weeks despite having time; you dread rather than anticipate working on it; the scope has expanded to the point where shipping feels years away; or your life circumstances have changed and the time budget no longer exists. Killing a project is not failure — it's portfolio hygiene. Document what you built and learned (a README or a post-mortem blog post), then move on. The lessons transfer to the next project. The hours spent aren't wasted just because the project didn't ship.
Update: I've since graduated from Swiss German University and now work full-time as an AI Forward Deployed Engineer at Commsult Indonesia. This post reflects where I was at the time of writing.