# Side Projects While Working Full-Time: A Real Strategy That Doesn't Destroy Your Life

> How to maintain meaningful side projects alongside a full-time job (or degree) without burning out — with actual time management, scope discipline, and shipping strategies.

URL: https://www.matthewswong.com/en/blog/side-projects-full-time/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2025-06-10
- Updated: 2026-10-17
- Category: Career

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.

> 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.

> **The Side Project That Becomes a Second Job**

> 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.

## 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 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.

## Sources & Further Reading

- Paul Graham — Startups in 13 Sentences
- Jason Fried & DHH — Rework
- Pieter Levels — Make: Bootstrapper's Handbook

> **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.

## Source links

- http://www.paulgraham.com/13sentences.html
- https://basecamp.com/books/rework
- https://makebook.io

## FAQ

### Why do most side projects fail before they ship?

Most side projects fail not from lack of ideas or technical skill, but from scope creep, loss of motivation after the initial phase, perfectionism, and the inability to maintain context across sporadic work sessions. The critical danger zone is the 'boring middle' — form validation, error handling, deployment config — where developers add nice-to-have features instead of shipping what already exists.

### How much time per week is realistic for a side project alongside a full-time job or degree?

A realistic budget is 5–10 hours per week, explicitly scheduled rather than treated as leftover time. The post uses weekend mornings (6–9 am) and one or two weekday evenings (7–9 pm). At 5 hours per week, roughly 130 hours of focused work accumulates over 6 months — enough to build, test, and deploy a simple but polished web application.

### What is the scope discipline principle and why does it matter?

Every new feature idea goes onto a list, and nothing from that list enters the current scope unless something else leaves it. The current version should contain exactly the features needed to be useful to one real user — no more. The MVP is not a starting point but the entire first version, because simple and shipped beats complex and abandoned every time.

### How can you reduce the context-switching cost of returning to a project after several days away?

Write short end-of-session notes in plain English — not code comments — describing what you were trying to fix, what error you hit, and what the next step is. Keeping a scratch markdown file per project for these notes turns a potential 20–30 minute re-orientation into roughly 5 minutes, saving an estimated 30–40% of effective project time that would otherwise be lost to context overhead.

### Should you use unfamiliar technology for a side project when time is tight?

No — when shipping is the goal, use boring, familiar technology. The post uses the same work stack (Next.js, TypeScript, PostgreSQL) for personal projects because there is zero ramp-up time. New technology experiments are reserved for explicit throwaway prototypes with no shipping expectation attached; mixing learning and shipping goals under time pressure is a reliable path to an abandoned project.

---

- HTML version: https://www.matthewswong.com/en/blog/side-projects-full-time/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/side-projects-full-time/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json