[{"data":1,"prerenderedAt":86},["ShallowReactive",2],{"blog-post-side-projects-failed-because-i-kept-making-them-better-en":3},{"id":4,"title":5,"author":6,"body":7,"cover":72,"description":73,"extension":74,"featured":75,"meta":76,"navigation":75,"path":77,"publishedAt":78,"readingTime":79,"seo":80,"stem":81,"tags":82,"__hash__":85},"blogEn\u002Fblog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better.md","My Side Projects Failed Because I Kept Making Them Better",null,{"type":8,"value":9,"toc":68},"minimark",[10,14,17,20,26,29,34,37,45,50,53,58,61],[11,12,13],"p",{},"I have this tendency, both as a developer and in life. I love reorganising things, cataloguing, restructuring, and moving pieces around until everything feels ergonomic and clean. For a long time, I told myself this was a strength. What I didn’t see was that I was cleaning up before I’d even made a mess.",[11,15,16],{},"No system is truly perfect, bug-free, and ready for every future feature. But my fear of technical debt pushed me into overthinking the architecture of a simple project for weeks. The logic sounded reasonable: build a scalable foundation upfront and save yourself pain later. And I still believe structure matters, even for small and medium-sized systems.",[11,18,19],{},"But every time I finished a refactor and started implementing a new feature, I noticed ways the previous design could be improved for this specific case. So I changed the base classes. Then the database model. And soon, almost every new feature was somehow “blocked” by another refactor.",[11,21,22],{},[23,24,25],"strong",{},"At some point, I had to admit that something in my process was broken.",[11,27,28],{},"Not the tools. Not the language. Not the framework. The way I was working. I was optimising for correctness and elegance instead of progress. And progress is what actually exposes bad decisions. Without it, I was just arguing with imaginary future problems.",[11,30,31],{},[23,32,33],{},"So I changed the rules for myself.",[11,35,36],{},"I separated time for refactoring from time for delivery. Refactoring became a planned activity. Everything else was about shipping: new features, small improvements, fixing bugs, and closing todos.",[11,38,39,40,44],{},"I created a file called ",[41,42,43],"code",{},"TECHNICAL_DEBT.md",". Whenever something felt wrong or ugly, I wrote it down instead of fixing it immediately. What hurts? Why did it hurt? What would I change if I had the time? I scheduled a recurring time slot in my calendar to address it.",[11,46,47],{},[23,48,49],{},"That changed everything.",[11,51,52],{},"The work became calmer. Decisions became lighter. I stopped fighting myself while writing code. I could move forward without pretending that every choice had to be perfect. What took me longer to understand is why this pattern existed in the first place. I knew the theory. Everyone knows it. Overcomplicating a project at the beginning is a mistake. Premature abstraction is dangerous. You should let the system grow.",[11,54,55],{},[23,56,57],{},"But knowing that was not enough.",[11,59,60],{},"My perfectionism was doing something more toxic. It would not allow me to acknowledge technical debt at all. Writing something down as “imperfect” felt like admitting failure. Like proof that I was not a good developer. Not making progress on my projects kept me going further down this spiral.",[11,62,63,64,67],{},"What I am learning now is that good systems are not born clean. They become clean through use. Through mistakes. Through pressure from real users and real constraints. Finishing things turned out to be more rewarding than designing perfect systems. And accepting technical debt turned out to be a form of ",[23,65,66],{},"maturity",", not a failure.",{"title":69,"searchDepth":70,"depth":70,"links":71},"",2,[],"\u002Fimages\u002Fblog\u002Fside-projects-launch.avif","How perfectionism and premature refactoring stalled my side projects — and the rules that helped me start shipping again.","md",true,{},"\u002Fblog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better","2026-02-02","2 min read",{"title":5,"description":73},"blog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better",[83,84],"Technical debt","Productivity","E11E8Gd7i2TGfjvl3JWoAfwUeUQJTxjyaQ5SaDmmsOQ",1787647489238]