3-Month Side Project Retrospective: Half Success, Half Flailing
I built a web service by putting in one or two hours after work each day, and it went into beta yesterday. Writing this retrospective to mark the occasion.
1. I held onto planning for too long
What should have taken two weeks took a month, and I was basically having meetings with myself. I would've been better off writing one more line of code in that time.
2. Don't overprovision infrastructure from day one
I started out adding autoscaling and all that, and with zero users I was only burning money on servers. Now it runs on a single cheap instance.
3. Don't ask AI about everything
Sure, productivity went way up, but there was a time I spent 30 minutes stuck on AI answers because I couldn't find the cause of an error. In the end, I solved it by looking at the logs myself. A tool is just a tool.
4. Biggest lessons
- A shabby launched service beats a perfect plan that never ships
- Users don't use the features I thought they would
- One piece of feedback is far more valuable than imagining things alone
For my next project, my goal is to cut planning down to three days and start building right away. If anyone has had similar trial-and-error experiences, please share your know-how haha.
6 answers
Agreed, especially #3 really hits home. I also wasted two hours because the AI kept confidently giving wrong answers and saying "This is all you need to do" lol. In the end, the logs were the answer.
Honestly, I'm not so sure about #2. It's true that over-provisioning from the start is wasteful, but if you try to add it later, isn't the migration cost even higher? When you have zero users, sure, starting with a cheap instance makes sense, but if you design the structure itself so it can't scale, you'll have to tear it all out later. The balance between "overdoing it from the start" and "not preparing at all" is what matters.