Why Most Side Projects Die on Day 14

There is a pattern I have noticed in myself and in every developer I know.

You get an idea. It feels electric. You buy the domain (of course you do). You set up the repo. You code furiously for a weekend. Maybe two weekends. And then, somewhere around day 14, the whole thing just... stops.

I have been tracking my own side projects for the last three years. Out of 23 projects started, exactly 4 made it past the one-month mark. The rest died somewhere between day 10 and day 18.

The Novelty Cliff

The problem is not laziness. The problem is that the first two weeks are all novelty. You are making decisions. Picking technologies. Designing the architecture. Every commit feels like progress because everything is new.

Then you hit what I call the Novelty Cliff. The scaffolding is done. The exciting decisions are made. What remains is the boring middle: error handling, edge cases, that one API integration that requires reading 40 pages of documentation.

What Actually Works

The projects that survived past day 14 had one thing in common: I told someone about them before I started coding. Not after. Before.

When you tell someone "I am building X," you create a small social contract. Not a big one. But enough that when day 14 arrives and you want to quit, there is a tiny voice saying "but you told Rajesh about this."

The Real Question

I do not think the answer is discipline. The answer is designing your projects so that the boring middle is smaller. Ship something embarrassingly small on day 3. Get one real user by day 7. Make the feedback loop so tight that you never hit the Novelty Cliff at all.

At least, that is the theory. I am on day 12 of a new project right now. Ask me again in a week.

• Mohan