Give Your Side Project a Kill Date Before You Even Write Line One
Let's be honest: your Notion sidebar is a graveyard. Somewhere between "crypto-powered dog food subscription app" and "Rust-based terminal emulator nobody asked for" sits a pile of half-finished projects that once felt urgent and now just feel like guilt. You open the folder occasionally, stare at a README with three bullet points and no actual code, then close it and go watch TV.
This is not a motivation problem. It's a structure problem.
The developers who consistently ship — the ones with actual GitHub activity graphs that don't look like a drought map — aren't more disciplined or more talented. They've just learned to treat side projects like perishable goods. They slap an expiration date on the package before they even put it in the fridge.
Why "I'll Finish It Eventually" Is a Lie Your Brain Tells You
There's a psychological concept called the planning fallacy — the deeply human tendency to underestimate how long things take while simultaneously overestimating how motivated Future You will be. It's why you think you'll clean out the garage "this weekend" every weekend for three years.
Side projects exploit this flaw mercilessly. When you start one with no deadline, you're essentially betting that your enthusiasm six weeks from now will match your enthusiasm today. It won't. Life happens. A new framework drops. A different idea grabs you. The project that felt electric on a Tuesday night feels like homework by the following month.
Open-ended projects also carry a hidden cognitive tax. Every unfinished thing in your mental inventory costs you something — a small but real drain on attention every time you context-switch back to it. Multiply that by five or ten abandoned side quests and you're walking around with a significant chunk of your creative bandwidth already spoken for, even when you're not actively working on any of them.
The Three-Day Experiment (And Why It Works)
Here's the move: before you write a single line of code, decide on a fixed window — often as short as three days, rarely longer than two weeks — after which the project either ships in some form or gets officially killed. Not shelved. Killed. Archived. Marked done-enough or done-never, and moved out of your active mental stack.
Three days sounds absurd until you think about what three focused days can actually produce. A working prototype. A proof of concept. A CLI tool that does one thing. A landing page that tests whether anyone cares. The goal isn't a finished product — it's a decision. Does this idea deserve more of my time, or not?
That's the real output of a time-boxed experiment: not code, but clarity.
When you know you've got 72 hours, you make different choices. You reach for the library instead of rolling your own. You skip the perfect folder structure. You use SQLite instead of setting up Postgres. You write the ugly version that works instead of the elegant version you'll never finish. Constraints force prioritization, and prioritization is where real engineering judgment gets built.
How to Actually Set Up a Project With an Expiration Date
This doesn't require a complicated system. A few practices that developers who use this approach tend to share:
Define the one thing you're validating. Before you start, write a single sentence: "This experiment will tell me whether [X]." If you can't fill in X, you're not ready to start. The question might be technical ("Can I build a real-time sync feature with this new WebSocket library?") or market-oriented ("Will anyone sign up for a waitlist for this tool?"). Either works. Vague doesn't.
Set a calendar event for the kill date. Not a sticky note. An actual calendar block that says "Ship or Kill: [Project Name]." Treat it like a sprint review. Show up to it.
Lower the bar for what counts as shipped. A GitHub repo with a working demo is shipped. A tweet with a screenshot is shipped. A blog post explaining what you learned is shipped. The point is to produce an artifact that exists outside your head, not to launch a company.
Write the postmortem before you start. This sounds weird, but it works. Draft a two-paragraph document that says: "I'm building this to learn X. I'll know it worked if Y happens. If it doesn't, I'll stop because Z." Having that document waiting means you're not making an emotional decision at the end — you're just checking against criteria you already set.
Killing Projects Faster Is Actually How You Build More
There's a counterintuitive thing that happens when you start killing projects decisively: you feel freer to start new ones. The fear of commitment shrinks. You stop treating every idea like a potential five-year relationship and start treating it like a first date — low stakes, time-limited, informative.
Developers who ship a lot often describe their creative process less like construction and more like farming. You plant a lot of seeds. Most of them don't grow. That's not failure — that's the system working. The ones that do grow, you water. The ones that don't, you clear out so they're not competing for nutrients.
Rapid iteration across many small experiments also builds a skill that no single long-running project can teach you: the ability to get productive in a new codebase, a new domain, or a new tech stack very quickly. Every time you spin up a three-day experiment with an unfamiliar tool, you're building that muscle.
The Projects Worth Extending
None of this means you should never work on something longer than a week. The kill date isn't a ceiling — it's a checkpoint. If you hit your expiration date and the experiment produced real signal (users showed up, the technical approach proved out, you can't stop thinking about it), then you make a conscious decision to extend it. But you make that decision explicitly, not by default.
The difference between a side project that grows into something real and one that rots in your repos folder is usually just that: intentionality. Did you choose to keep going, or did you just... never stop?
Set the kill date. Ship or kill. Then start the next one.
That's the loop. Build. Ship. Repeat.
