Side Project Economics: Shipping When Nobody's Paying You

Most side projects die. Not from technical failure. From entropy. You start excited, build the fun part, hit the boring part, slow down, get busy at work, miss a weekend, miss two, and one day you realize it's been a month since you opened the repo.

This has happened to me roughly seven times. Here's what I've learned about why, and what I'm trying differently this time.

The first 30% is free

Every side project gives you a free dopamine ride at the start. You're picking the tech stack, naming the project, setting up the repo, drawing the first wireframe. None of it is hard, all of it feels like progress.

This is the trap. You confuse the energy of starting with the durability of building, and you take on too much. You imagine the finished product, and that imagination feels almost as good as actually shipping the finished product, so you don't quite need to ship it.

I think the first lesson of side project economics is: treat the starting energy as a non-renewable resource. It's the only fuel you'll get for free. Spend it on the hard part, not on the easy part. Set up the boring infrastructure last, not first. The hard part is the part you'll need a reason to push through, and starting energy is your only reason at the beginning.

Boredom kills more projects than difficulty

Difficulty I can deal with. If something is hard, I get curious. I read, I prototype, I struggle, I learn. Hard is engaging.

Boredom is what kills me. Once the interesting problem is solved and what's left is form validation, settings screens, edge cases, and writing the README, my brain leaks out. Other ideas start looking more attractive, precisely because they're new and the new project is back at the fun part.

The trick I've learned: never end a coding session by finishing something. End in the middle of something interesting. Future-me, sitting down on a tired Sunday evening, will not start a session if it begins with "okay, now write the unit tests." Future-me will start a session if it begins with "okay, the half-built thing from last night just needs ten more minutes."

It's the same trick writers use. Stop in the middle of a sentence so you know how to begin tomorrow. Same logic, same psychology, same result.

Public > private

The other thing that's worked: doing it in public. Not in a heavy "build in public" way with daily threads and screenshots, but just — telling a friend what I'm building, posting an occasional clip, writing a blog post about a problem I solved.

This works for a slightly cynical reason: a project I've told people about has a small social cost if I abandon it. Not a big one. Nobody is checking on me. But the existence of even a few people who know the project exists creates a thin pressure that private projects don't have.

For me, the right amount of public is small. A weekly note, a monthly video, a blog post when something interesting comes up. Enough to feel accountable. Not enough to feel performative.

Scope is the budget

The single biggest lesson, the one I keep relearning: the scope you imagine at the start is roughly 4x what you'll actually ship. Plan accordingly.

I now do this consciously. When I sketch out a new project, I list every feature I want. Then I divide the list into thirds. The top third is the MVP. The middle third is "if I'm still excited at week six." The bottom third is "if this becomes a thing." Then I delete the bottom third entirely and forget it exists, because keeping it on the list will pull my attention toward it.

This sounds harsh. The thing is, the bottom third is usually the part you imagined most vividly when you started — the killer features, the polish, the "wouldn't it be cool if." Those are the daydreaming parts. They're what got you excited, but they're not what gets you to a shipped thing.

You ship the MVP. If anyone uses it, you build the middle third. If a lot of people use it, you find that bottom third still exists in your brain, and you build that too. But you never start there.

Money isn't the metric

The "economics" framing of this post is a little misleading. Most side projects I work on will never make money, and that's fine. The economics that matter are different:

Energy spent vs. energy gained. If I finish a coding session more energized than I started, that's positive. If I finish drained, the project is taxing me, and a few sessions like that and I'm done.
Skill compounding. Did I learn something this session that I can use elsewhere? Side projects are paid in skill, not cash. The good ones pay well.
Permission to ship something weird. At work, I can't ship a game where the budgeting categories are RPG quests. On a side project I can. The economic value of that permission, over a career, is huge.

If a side project loses on all three of those — drains my energy, doesn't grow my skills, doesn't let me make something weird — it's a bad investment, and I should kill it. The hard part is being honest about which projects those are, because I almost always want the project to be good. Wanting is not the same as it being good.

What I'm trying this time

The current side project, which I won't name yet because I'd like to actually finish it before talking about it: I've scoped it to a single weekend's worth of work. I've told two people. I've structured the codebase so I can stop in the middle of a feature and pick up where I left off. I've committed to shipping it bad before making it good.

We'll see if it works. The honest answer is that most of these projects don't, and the only way to find out which ones will is to try. Side project economics, at the end of the day, is just doing this often enough that the law of large numbers eventually delivers one that sticks.