Product4 min read

Why most side projects never ship

The patterns I've noticed in projects that actually make it to production versus the ones that collect dust.

I have a graveyard of unfinished projects. Half-built apps sitting in private repos, domain names I bought in a burst of enthusiasm that now auto-renew quietly every year. If you're a developer, you probably have something similar.

Over time I started noticing a pattern. The projects that ship and the ones that don't have almost nothing to do with the quality of the idea or how excited I was at the start. The difference comes down to a few specific behaviors that I can now predict within the first week.

The excitement trap

Every new project starts the same way. You get an idea, usually in the shower or while half-asleep, and suddenly you can see the whole thing. The landing page, the features, the onboarding flow. You open your laptop and start building immediately.

This is the riskiest phase. You're high on possibility and you make decisions that feel productive but aren't.

You set up a monorepo when a single folder would do. You configure CI/CD before you have anything to deploy. You spend an afternoon choosing between 3 icon libraries.

None of this moves you toward a working product. It moves you toward a well-configured project that doesn't do anything yet.

Scope is the killer

Scope kills side projects more often than technical complexity, lack of time, or fading interest.

When you're planning in your head, everything seems small. "It's a dashboard with some charts." Then the dashboard needs auth. Auth needs email verification. Email verification needs a transactional email setup.

The charts need data, which needs an API, which needs a database schema, which needs migrations. Suddenly your "simple dashboard" is a 2-month project.

The projects that ship are the ones where I ruthlessly cut scope before writing a single line of code.

I ask myself what the absolute minimum is for the project to be useful. Then I cut that in half, because my first answer is always too ambitious.

Time boxing works

The best trick I've found is giving myself a hard deadline. Instead of "I'll try to finish this in 2 weeks," the rule becomes "this ships on Friday or it doesn't ship at all."

When you have a real constraint, you make different decisions. You skip the custom design system and use defaults. You hardcode things that could be configurable. You deploy to Vercel instead of setting up your own infrastructure.

These shortcuts feel wrong in the moment. A shipped product with hardcoded values beats an unshipped product with a beautiful config system every time.

Build the core loop first

Every product has a core loop. It's the thing the user does repeatedly.

For a todo app, the loop is adding and completing tasks. For an analytics tool, it's viewing a dashboard. For a social app, it's posting and reading.

Build that loop before the onboarding, settings page, or billing.

If the core loop isn't interesting, no amount of polish will save the product. If the loop is interesting, everything else can be rough and people will still use it.

I shipped the first version of 21metrics with no landing page, no onboarding, and a login flow that was literally "enter your email." The core loop worked, and that was enough to get the first 50 users.

The finish line problem

The last 10% of a project takes 50% of the time. This is where many side projects die, because you've solved the interesting problems and all that's left is the tedious stuff.

Error handling. Edge cases. Mobile responsiveness. Terms of service pages.

You have two options here. Either push through the tedium because you're committed to shipping, or accept that this project isn't going to ship and move on to the next thing. Both are valid.

Sitting in the middle rarely works. Spending a few hours every weekend on something you've lost enthusiasm for creates incremental progress that never quite gets you to done.

Ship something this week

If you have an idea you've been thinking about, here's my challenge: build something and ship it in 1 week. Make it something with a URL that another person can visit.

It can be rough and incomplete. It needs to exist in the world where someone else can see it.

The gap between "I could build this" and "I built this" is enormous, and shipping is the only way to close it.

Want to work together?

I help companies design and build products from the ground up. Let's talk about your project.

Get in touch