The side project graveyard is the largest cemetery on the internet. Every developer, writer, designer, maker, and founder-in-waiting has one. It is populated by half-finished MVPs, abandoned newsletters, broken landing pages, unlaunched products, and the universal artifact: a Notion page titled "ideas" that has been untouched since 2023.
The common explanation is that people do not have time. That is rarely the real reason. People with families, full-time jobs, and long commutes have historically built remarkable things in the margins. The real reasons side projects die are structural, and they are fixable once you name them.
This is the honest guide to actually finishing a side project, written for people who already know they should be more disciplined and have not managed it. It will not tell you to wake up at 5 a.m. It will not tell you to quit your job. It will tell you specific, small changes that make shipping more likely.
Why Side Projects Die
There are three dominant failure modes. They usually stack.
First, scope creep before launch. You start building a note-taking app, and by week four you are also building a team collaboration feature, a Chrome extension, a mobile app, and a social network around note-taking. The one thing you could have shipped in three weekends becomes a thing you could ship in three years, which means you ship nothing.
Second, no forcing function. The day job has meetings and deadlines. The side project has neither. Without an external anchor — a commitment, a launch date, a paying customer — the side project is always optional, which means it always loses when life gets busy.
Third, the dopamine of starting exceeds the dopamine of finishing. Starting a new project feels great. Finishing one is 80% grind. Most people are addicted to the first and have not built the muscle for the second, so they start more projects instead of finishing the one they have.
All three failure modes are addressable.
The One-Weekend Test
The most effective scope control is to ask the question: what could I ship in one weekend? Not "what would be good to ship in one weekend" — what could I actually finish, end-to-end, in sixteen hours of focused work on a Saturday and Sunday?
The honest answer is usually much smaller than you assumed. A single landing page with a signup form. A one-feature tool with no authentication. A personal blog with three posts. A browser extension that does one thing.
The small scope feels unsatisfying because you imagined shipping something bigger. That is the point. The small version is the version that actually ships, and a shipped small thing is infinitely more valuable than an unshipped ambitious thing. You can expand later. You cannot expand nothing.
Build the one-weekend version first. Launch it publicly. Then, and only then, consider whether to expand.
Build a Forcing Function
Side projects need external accountability because internal accountability dries up when the week gets hard. The specific form of the forcing function matters less than having one.
- A public launch date. Tell people, in a specific message to a specific community, that you will ship by a specific date. Writing it on Twitter to no one does not count.
- A paying customer before you build. Pre-sell. Even a single $50 commitment from a real person transforms the motivation profile of the project.
- A co-builder. Someone who is expecting you on Sunday morning and will notice if you do not show up.
- A community that ships. Groups like Ship30 or Indie Hackers create peer pressure that is gentler than a deadline but sharper than no accountability.
Projects with any of these forcing functions ship at roughly 5-10x the rate of projects without them. The difference is not willpower. It is architecture.
Pick the Evenings You Can Actually Defend
Most people try to do side projects at night, after work, after family, when they are exhausted. This almost never works. An hour of post-10pm energy produces less output than twenty minutes of fresh morning energy, and it steals from sleep you needed.
The realistic side-project windows for most adults:
- Saturday morning, 7-10 a.m. The single best window available. Fresh, quiet, sustained.
- Sunday afternoon, 1-4 p.m. Less effective but usable.
- A single weekday evening, 8-10 p.m. Only one. Two evenings a week is not sustainable over months.
- A single weekday morning, before work. If you can wake up an hour earlier without wrecking your sleep.
Most successful side-project shippers use two of these windows consistently. Not four. Not five. Two. The consistency matters far more than the total hours.
Make It Boring to Resume
The cost of resuming a side project after a week away is the main reason side projects stall. You open the code or the doc, cannot remember what you were doing, spend forty minutes re-orienting, and give up because the session ended before you made real progress.
The fix is an end-of-session note. Every time you stop working on the project, spend two minutes writing — or dictating — a single paragraph: what you just did, what the next concrete step is, and any notes on what you are stuck on. When you resume next week, you read this paragraph in thirty seconds and are immediately oriented.
This practice alone dramatically increases the probability of finishing a side project, because it removes the largest single source of stalling. A dictation tool is useful here — two minutes of speaking produces a richer note than two minutes of typing, and the resume context is better. Voice Keyboard Pro at voicekeyboardpro.com is free if you want a tool that drops transcribed notes into any app on a Mac.
Ship Publicly, Early
The worst thing you can do for a side project is keep it secret until it is "ready." It will never be ready. The right move is to ship something publicly while it is still embarrassingly small. A landing page. A one-feature demo. A blog post describing what you are building. This creates small, real-world feedback loops that sustain the project far better than internal motivation alone.
Public shipping also triggers a useful psychological effect: once people are aware of the project, the cost of abandoning it is higher, which means you keep going through the discouraging middle where most projects die.
The side projects that ship are almost always the ones that shipped something small, publicly, early. The ones that die are almost always the ones that were going to be unveiled, polished, when they were ready.
One Project at a Time
Most side-project underachievers are running three to five projects simultaneously. None of them ship because attention is split. The first and hardest discipline is to pick one project and give it exclusive attention for a fixed window — eight weeks, twelve weeks — during which no other project gets touched.
The other projects will still exist after the window. The world is not going anywhere. Pick the one you can actually finish in the window and finish it.
The "Done" Definition
Projects without an explicit definition of done drift forever. Before you start a side project, write down — in one or two sentences — what "done" looks like. "Landing page with signup form, one-paragraph description, deployed to a custom domain, and shared in three communities." That is done. Everything beyond that is scope creep, and you are not doing it until you ship the done version.
This sounds trivial. It is the single largest behavioral change for people who repeatedly fail to ship. Most side projects have no definition of done, which is why they have no ending.
Accept That Most Projects Are Small
A lot of side-project frustration comes from the gap between the imagined scale of the project and the realistic scale a part-time maker can actually achieve. You imagined building the next Notion. You are building a single-page tool that does one thing well. That is fine. It is more than fine. A lifetime of small shipped things is more impressive than a lifetime of big imagined ones.
Reset the ambition to match what you can actually do in your real-life constraints. Ship the small version. Then ship another small version. Over five years, a hundred small shipped things accumulate into something substantial, and each one individually was doable because you scoped it honestly.
The Burnout Question
The "without burning out" half of this article's title is not rhetorical. Side projects done badly accelerate burnout. Done well, they are protective — they give you a creative outlet outside your day job, an identity beyond your title, and a sense of agency that a salaried role sometimes suppresses.
The line between energizing and burning-out side projects is usually about sleep and social life. If the side project is costing you sleep or costing you time with the people you care about, the project is too big for your current life. Scale it down or pause it. The projects that compound are the ones that are sustainable.
This also means some seasons are not side-project seasons. New baby, demanding quarter at work, a family member's health crisis — these are times to pause, not push through. The projects will still be possible in three months. The relationships may not be.
A Realistic Year of Side Projects
A reasonable annual target for a working adult with a day job and a life: two to four shipped projects, each built in a focused six-to-twelve week window. Gaps in between for rest. Public launches. End-of-project retrospectives. Ideally one small thing that compounds into something bigger.
That is a great year. It looks quiet from the outside. It produces more than most people's multi-year "I'm working on something big" promises.
Getting Started This Weekend
Pick a project. Define what "done" looks like in two sentences. Commit to a public launch date six to eight weeks out. Block Saturday mornings. Tell at least three people what you are building.
That is the entire setup. Everything after is execution, which is much simpler once the frame is in place.
The maker's mythology is about heroic effort. The reality is about scoped ambition, consistent small windows, and the discipline to ship the boring first version before the imagined second one.