You Haven't Started Your Side Project. You've Started a Side Project About Your Side Project.

You Haven't Started Your Side Project. You've Started a Side Project About Your Side Project.

Congratulations. You have an idea. A genuinely good one, possibly. You've told three friends about it. Two of them said "that's actually kind of cool" and one said "I think someone already built that" and you've been stress-researching competitors for four days. The GitHub repo exists. It has a name. The name took two hours to choose and you're still not fully at peace with it.

The code directory contains exactly one file: .gitignore.

Welcome to the side project paradox, where the act of preparing to build something has become indistinguishable from actually building it — except for the part where anything gets built.

1. You've Chosen Your Tech Stack Three Times

The first stack was React with a Node backend. Then you read a blog post about SvelteKit and the scales fell from your eyes. Then a coworker mentioned they'd been messing around with Htmx and you fell down that rabbit hole for a weekend. You are now on your fourth architecture decision and you haven't written a single route.

Here's the thing: for a side project with zero users, the tech stack matters approximately as much as the color of your invisible car. Ship something. Anything. The stack you know is infinitely better than the stack you're still benchmarking.

2. Your Dev Environment Is a Work of Art

You've spent three days configuring your terminal. You have a custom Neovim setup with seventeen plugins, a color scheme you adjusted manually, and a dotfiles repo that is — and this is not a joke — better documented than any professional project you've ever worked on. Your shell prompt shows the current git branch, battery percentage, the phase of the moon, and your emotional state inferred from recent commit messages.

This is genuinely impressive. It is also a masterclass in displacement activity. Your IDE does not need to be perfect before you write code. The code needs to be written before your IDE needs to be perfect.

3. The README Is Longer Than the Codebase

You've written an introduction, a features section (future tense, all of it), a getting-started guide for a project that cannot be gotten started, a contributing guide for contributors who do not exist, and a license. The README has a badge. The badge is for build status. There is no build.

Somewhere, a product manager is reading this and nodding with a complicated expression.

4. You're Waiting for the "Right" Weekend

Not this weekend — you've got that thing. Not next weekend, because you'll be tired from the week. The weekend after that is Memorial Day and you should really be present for that. But the weekend after that? That's the one. That's the weekend where everything aligns and you enter a flow state and emerge forty-eight hours later with a functioning MVP.

Psychologists call this temporal discounting. The future version of you is always more motivated, better rested, and mysteriously free of obligations. The present version of you has been saying this for four months.

5. You've Designed the Logo

Not just a rough sketch. A full logo, with variants, in light and dark mode, exported at multiple resolutions, with a color palette documented in a Figma file you shared with no one. The icon is clean. The wordmark is tasteful. The brand guidelines specify the minimum clear space around the logo.

The app has no screens.

This is actually a well-documented psychological phenomenon: completing peripheral tasks gives us the same neurological reward as completing central ones, with significantly less risk of discovering that our idea doesn't work. A logo cannot fail. Code can. The brain, being cowardly, prefers the logo.

6. You've Explained the Architecture to Your Cat

Or your partner. Or your Notion doc. You've drawn the system diagram. You know how the microservices will communicate once you have microservices. You've planned for scale you will not reach for years, if ever, and you've made architectural decisions that protect against problems that don't exist yet at the expense of solving the one that does: there is no app.

This is impostor syndrome in a trench coat. If we plan perfectly enough, we can't be blamed when it doesn't work. Planning is a shield. The only cure is shipping something embarrassingly small and surviving the experience.

7. You've Rewritten the Folder Structure Twice

The first structure made sense at the time. Then you read an article about feature-based organization versus layer-based organization and restructured everything. Then you found a different article that argued the opposite and you're now in a superposition of both approaches, folders nested inside folders, awaiting the architectural observation that will collapse the waveform.

There are four files in this folder structure. Two are configuration. One is the README. One is .gitignore. They are exquisitely organized.

8. You've Benchmarked Hosting Options With the Rigor of a NASA Mission

You have a spreadsheet. It has columns for pricing tiers, cold start latency, free tier limitations, geographic availability, and vibes. You've read the Hacker News threads. You've watched the YouTube comparisons. You know more about the infrastructure of your unbuilt application than most engineers know about systems they've run in production for years.

For a side project, until it has users, the correct hosting choice is "the one you can deploy to in the next fifteen minutes." That's it. That's the whole framework.

9. You've Started a Second Side Project to Avoid the First One

The first project got complicated. The scope crept. The tech choices felt constraining. So you started something smaller, just a little tool, almost a utility really, nothing serious. The new project now has its own README, its own logo sketch, and its own carefully considered folder structure. The first project watches from its abandoned GitHub repo with the quiet dignity of a project that at least got further than .gitignore.

10. You're Reading Articles About Side Projects Instead of Building Yours

Yeah. We see you. You're here right now. This is fine — we appreciate the traffic — but at some point the meta-activity has to end and the actual activity has to begin.

The Survival Guide (Seriously, Ship Something)

Here's the only productivity advice that actually works for side projects, delivered without irony: make the first version embarrassingly small.

Not MVP. Not Minimum Viable Product. Minimum Embarrassing Product. The thing so stripped down that you're almost ashamed to show it. That thing. Ship that. The psychological barrier to a second version is one percent of the barrier to a perfect first version, and the second version is where you learn what the project actually needs to be.

Set a timer. Two hours. No stack research, no logo work, no folder structure debates. Just the smallest possible thing that does the one core thing your idea is supposed to do. It will be ugly. It will be incomplete. It will exist.

Existing beats perfect every single time. The null terminator of software development isn't a bad architecture decision or a wrong tech choice. It's the project that never shipped at all.

Now close this tab. Open your editor. You've got a .gitignore file that's been waiting long enough.