What I Learned from Building 3 Side Projects

Let's Start with the Coffee App I Abandoned in Week 2

I tried to build a coffee logging app with React Native. A simple app to record the beans, brewing method, and taste notes for every coffee I drank, then show stats. Supporting iOS and Android simultaneously seemed efficient.

I gave up in week 2. Native module compatibility issues broke the build, and I spent way too long trying to fix them. I didn't implement a single feature I actually wanted. Lesson learned: chasing "a tech I want to learn" and "a product I want to build" at the same time means you fail at both.

Over the past two years, I built three side projects. One succeeded, one was abandoned like the coffee app, and one only I use.

The Bookmark Service: Briefly Hit Product Hunt Top 20

The first project was a bookmark service for developers. Pocket felt too generic, so I wanted something optimized for devs. I built an MVP in two weeks with Next.js + Supabase and added a Chrome extension for one-click saving.

I posted it on Product Hunt and it hit the day's top 20. Users grew to 300. But that's where it stalled. Responding to user feedback, fixing bugs, managing the server -- it ate up all my after-work energy.

By month three, I stopped updating. Users gradually left.

Building a side project isn't the hard part -- maintaining it is.

Work Hours Tracker: Still Using It Daily After a Year

The third project was a CLI tool that automatically logs work hours based on Git commit timestamps. I was tired of writing monthly work hour reports.

Since it was just for me, there was no pressure. I built the CLI in Go and finished in three days. No UI, minimal error handling -- nobody else needed to use it.

(Honestly, I just wanted an excuse to try Go.)

The funny thing is, this is the project I've used the longest. Over a year of daily use. The best user of a side project is yourself.

Common Takeaways from All Three

First, you need something working within two weeks. Any longer and you lose interest.

Second, the optimal tech stack is one thing you know + one new thing. If everything is new, you'll just be yak-shaving until you give up.

Third, don't aim for perfection. You don't need 100% test coverage on a side project. If it works, it works. Refactoring can wait. Actually, you might never need to refactor, and that's fine.

Impact on My Career

Building the bookmark service taught me Supabase, which I later used at work. The Go CLI taught me Go, which led to building internal tools in Go at my company.

No direct revenue, but the technical growth and confidence were real. A nice bonus: I could confidently answer "do you have any personal projects?" in interviews.

Planning Side Project Number Four

I've set rules. Only familiar tech. Deploy an MVP within two weeks. Build it on the assumption that I'm the only user. Just finishing it is enough.