What I Learned From Shutting Down a Side Project After 6 Months
Last week, I effectively shut down a side project I started at the end of last year. It got to 300 users, but growth completely stalled there, and more than anything, it took me a long time to admit that I didn't want to build it anymore.
At first, I rationalized it as "People aren't coming because it lacks features," but when I looked at the logs, the reality was that repeat visits weren't happening at all. It wasn't a feature problem—I started to question whether I even wanted to solve this problem in the first place.
I spent about 400,000 won, including server costs, and 6–8 hours every weekend. Sometimes I wonder what it would've been like if I'd used that time to do better at work, and other times I think that if I hadn't done this, I wouldn't have learned anything.
Here's what I learned:
- If you start coding without planning, you will definitely waste three weeks
- Five user interviews are better than ten features
- Set up deployment automation from the start, no matter what. Later, you'll be too bothered to do it
- "Just one more weekend" adds up to six months
Next time, I'm going to start with something much smaller—something I can finish within four weeks.
7 answers
Agreed, deployment automation really needs to be done from the start. If you put it off until later, you just won't get around to it.
Well, isn’t it a bit hasty to shut it down based on a single log showing no return visits? If even one person out of 300 is still using it, you should have asked that person. It’s their call that the feature isn’t the problem, but in reality everyone might have dropped off during onboarding.
I also shut down three side projects, and what you’re left with in the end is ultimately the answer to “why did I build this?” Adding features is fun, but it rarely leads to growth... That said, honestly, 300 users sounds like it went pretty well. Mine stopped at 30 lol.