Side projects that compound

Most CS students have a graveyard of half-built side projects. A Discord bot from freshman year. A todo app from a tutorial. A recommender system that almost worked. A scraper they meant to deploy. None of them are running, none of them are linked from the resume, none of them produced a follow-up. The work was real. It just didn’t compound.

The students whose projects do compound are not smarter or more disciplined. They’ve stumbled into a recognisable shape — small enough to ship, narrow enough to talk about, public enough to get feedback, useful enough to one real person — and they ride that shape over and over. After two years, that pattern is most of their resume, most of their network, and most of the leverage they have when they walk into an interview.

This module is the shape. Read it once before you start your next project. Score everything you build against it. The rest of this track assumes you do.

Set up — pick your three candidates

Before you read another paragraph, write down the three side projects you’ve been thinking about lately. Not “ideas in general.” The three you’d actually start this Saturday if you had to pick. One sentence each. We’ll come back to them at the end and score each one against the five properties.

If you can only think of one — write it down anyway, then keep reading. By the end you should have three.

Read these first

You don’t need to read these to do the assignment. Read them if you want the longer version of why this works:

1. Patrick McKenzie — Don’t Call Yourself a Programmer. post · 25 min · the canonical “your work matters more than your title” piece, still right.
2. Will Larson — How to invest in technical infrastructure. post · 15 min · the heuristic for “is this worth working on” generalises beyond infra.
3. Julia Evans — How I make zines. post · 10 min · the most underrated essay on shipping small narrow things in public.
4. Cal Newport — So Good They Can’t Ignore You (chapters 4–6). book · 45 min · the “career capital” framing this module is downstream of.

Stop after these four. The “side hustle” content industry on the internet is huge and almost entirely useless for engineers.

Why side projects die in week three

There’s a depressingly consistent failure mode. You start on a Saturday, big energy, scope is enormous. By Tuesday you’ve hit the first real engineering problem. By the next weekend, the novelty has worn off but you’re nowhere near a demo. You tell yourself you’ll come back to it. You don’t.

Three things kill projects in week three:

• Scope. “A platform where people can…” projects almost always die. Anything that requires three coordinated parts to be useful won’t get past part one on evenings and weekends.
• No audience. A project nobody else has seen has no external pressure. Your motivation is the only fuel. Your motivation does not last three weeks.
• No feedback loop. Even with an audience, if you can’t tell whether the thing is working — no users, no metrics, no comments, no PRs — you’re just typing into a void. Brains don’t keep doing that.

The five properties below are direct counters to those failure modes. Together they describe a project shape that survives.

The five properties of a compounding project

Score each candidate from 0 to 2 on each. A project that scores 8 or higher is worth starting. Below 6, you’re about to lose two months.

#	Property	What it actually means
1	Ship-able in 2 weeks of evenings	A v0 that you can demo by week 2, even if it’s ugly. About 20–30 hours of real work.
2	At least one real user (can be you)	Someone, ideally not you, will actually use this on a Tuesday afternoon. Not “would in theory.”
3	Narrow public artifact	One URL, one repo, one screenshot, one tweet. Not a “platform.” A thing.
4	Generates a follow-up question	Finishing v0 makes the next step obvious. “Now I want to add X” or “I wonder why Y is slow.”
5	Repeatable on a Tuesday	The kind of project you could plausibly do again, slightly differently, three months from now.

Property 4 is the one most students miss. A compounding project is not “the project that’s done.” It’s the project that opens a door — a follow-up writeup, a new feature, a comparison to someone else’s version, a spinoff library. That’s why it compounds. The first project is the seed, not the harvest.

Six categories that actually compound for students

When students ask me “what should I build”, I give them this list and tell them to pick one box and stay in it for a year.

Category	Example	Why it compounds
A tool you yourself use weekly	A CLI that bulk-renames files the way you actually rename them	You’ll keep using it, which means you’ll keep improving it.
A tiny SaaS / web app	A site that shows your dorm’s laundry-machine availability	Real users, real bugs, real feedback. Even 10 users teach you more than 10 tutorials.
An explainer site	”I built a transformer, here’s how each piece works” with diagrams	Compounds via SEO and shares. Most students are surprised how much traffic these get.
A library other devs need	A small Python package that does one thing well	Stars, PRs, GitHub graph activity. Recruiters look at this.
A benchmark / eval	”I ran 8 LLMs on 200 of my own coding problems, here’s what I found”	Data is the most shareable artifact in 2026. Reposted by the people whose models you tested.
A from-scratch writeup of a paper	”I implemented FlashAttention in 200 lines, here’s what surprised me”	Recruiter signal off the charts. Almost no students do this.

What’s missing from the list: clones of existing apps with no twist (Twitter clone, Spotify clone, Uber clone). They teach you frontend plumbing, sure. But they fail property 3 (no narrow artifact — there’s a thousand of them) and property 2 (nobody uses your clone). Build one if you must, then move on.

Scope a v0 you’ll actually finish — the demo-screenshot rule

Here is the single trick that does more for project completion than anything else. Before you write a line of code, write the demo screenshot caption. One paragraph, present tense, describing what someone sees when they open your finished v0 for the first time.

“You land on a single page. There’s a search box. You paste a GitHub repo URL. Within 5 seconds, the page shows a one-paragraph summary of what the repo does, the three most-edited files, and a button to open it in Cursor. That’s it. No login, no nav.”

If the caption takes more than 4 sentences, the scope is too big. Cut it. Cut it again. The constraint is not “what would be cool” — it’s “what’s the smallest thing that produces a demo-worthy screenshot in 2 weeks.”

Then work backwards from that screenshot. Every feature that doesn’t appear in the screenshot is in v1, not v0. Every feature in the screenshot is non-negotiable for shipping.

The 30-minute exercise

You wrote down three candidates earlier. Now do this:

1. Write the demo-screenshot paragraph for each. Aim for 4 sentences, present tense, describing what a first-time user sees.
2. Score each on the 5 properties (0/1/2 each, max 10).
3. Cross out any that score below 6. Don’t argue with yourself about it.
4. Of the remaining, pick the one where the demo paragraph excited you most when you wrote it. Not the most ambitious. The most exciting to actually finish.
5. Write a 2-week plan: what is week 1’s milestone, what is week 2’s milestone, what is the artifact you’ll ship publicly at the end.

That’s the project. The other two go in a parking lot file. They’re not bad — they’re just not now.

The opinion

Your portfolio needs ONE good project, not five mediocre ones. This is the take most students refuse to internalize, which is why most students have five mediocre ones.

A recruiter looking at your GitHub for ninety seconds is not going to read all five. They will glance at your pinned repos, click the one that looks most polished, and decide. If that one is half-finished, no README, no demo link, no screenshot — the other four don’t save you. They make it worse, because they signal that “half-finished” is your default mode.

So: pick one. Finish it. Ship it. Write about it. Then start the second.

Going deeper

When you have specific questions, in this order:

1. Simon Willison — How I write — and run — my blog. post · 15 min · the most repeatable solo-engineer workflow there is. Steal it.
2. Indie Hackers — milestones — read the milestones of any indie project that took off. Look at how small v0 was.
3. Pieter Levels — MAKE: Bootstrapper’s Handbook. book · skim · ignore the bro tone, keep the principles about shipping fast and narrow.
4. Tyler Cowen — Talent (chapters on agency and curiosity). book · skim · what successful young builders actually look like.

Skip “side hustle in 30 days” content. None of it generalises to real engineering.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. Name the three things that kill side projects in week three. Which one killed your last dead project?
2. List the five properties of a compounding project. Score the project you’re working on right now against all five.
3. What is the demo-screenshot rule, and why does it work?
4. Pick two of the six categories. For each, name a project shape that would compound for you specifically given what you already know.
5. Why does “your portfolio needs one good project, not five mediocre ones” override the instinct to start fresh on something new every month?

If you can answer all five from memory, you’ve earned 06.1. The next move is 06.2 — open source, the most under-priced career move in CS.