Tools: 6 Mistakes I Made Building a Side Project for Over a Year

Introduction ## Understanding the Consequences of Your Tech Stack ## Understand Your Core Features Early ## Overengineering Is Real ## Trying Too Hard to Validate Your Ideas ## Don't Make It a Job ## Be Proud of What You Make ## Now Go Be Awesome! For the past year, I've been working on a side project called computerscienceresources.com. I've noticed that there is no centralized location for the diverse range of computer science resources. I've seen GitHub repos for Awesome Lists. But, these static lists are hard to filter by community reviews and become outdated. In addition, I see a multitude of unknown ways to break into various software fields, but these resources are scattered all over the place and sometimes generally hidden. Furthermore, I sometimes hear a lot about some resources, like Brilliant, from all these YouTubers. And, as a skeptic, I want to know how good or bad the resource is: the teaching quality and engagement. Then, there is another issue of people asking me what resources I should recommend for getting into software. And the lack of a centralized website has led me to develop computerscienceresources.com. But today is not about promoting my site. I have been developing this site for well over a year now. I've made numerous mistakes since the beginning. I think that some lessons can only be learned from developing a long-term project, as this was my first project that was not just a throwaway toy project. Enough chit chat. I'll start with the lessons. After reviewing various options for my tech stack, I chose Laravel because it places a strong emphasis on developer friendliness, boasts a robust ecosystem, and is a mature MVC framework. I did investigate other options like Supabase, Phoenix with Elixir, Node.js, and the .NET framework. However, Laravel's ecosystem seemed much stronger for the kind of work that I wanted to get done. However, you must also understand that some frameworks are less "sexy" than others. When you limit yourself to a tech stack like Laravel, where the language is PHP, you may get fewer job opportunities than with a more popular one. Even if you end up creating a less robust application, recruiters like seeing popular frameworks like Node.js on your resume. I've had several interviewers question why I am using PHP in 2025. No doubt that if I chose a web framework like Spring Boot, Django, or ASP.NET Core, which uses more popular languages, interviewers would be more impressed. But I don't think that the language mattered much to me. I was more focused on getting my application published. I knew that coming in, the flashiness of the language was not important. With the scaffolding that Laravel provided, I was able to get a prototype up and running and develop my application with great speed, as Laravel provides a very nice starter kit. More importantly, I think the architectural decisions and software skills I've learned from this project apply to software development holistically. In this case, I've become very proficient with the MVC pattern. The lesson to learn here is that recruiters don't understand that one can become proficient with a framework by only having worked with similar ones. I'm certain I could pick up Django without much difficulty now (having done Laravel) — but to a job recruiter, they don't see that. No matter what framework you choose, understand what you want to achieve with your project: practicality or flashiness. If you are going to work on this project for a long time, define what the MVP would look like. It is common advice to work on an MVP for a project and to have a list of minimum features that your application would contain. I'm not going to explain all that; I know my audience is smart. So, I created a list of top features and split them into vital features of the application and "nice-to-haves." Of course, for a site with resources, I had posting and filtering resources as a top priority. Then, I trimmed the core features into a smaller subset of features to create the smallest possible core feature set: What I made a mistake in was not understanding the effort that each feature was going to take. I had some features in creating a resource be very important, such as having a multistep form save to local storage. However, I focused too hard on it during the beginning, thinking it was a trivial task — originally done with jQuery. I focused so hard on this feature to even work nicely with so many different web components and inputs that I could barely even have the MVP's core features met. What ended up happening was I spent a few months on a prototype with Laravel and Blade, with terrible code, and not even all the core features completed. Some features were much more complex than initially expected. One of them, which I will dedicate an entire technical article to later, was creating a nested comment system like Reddit. I managed to create one in-house, but it ended up not being a core feature at all. I could've saved a couple of months and launched the app early. In the end, I rewrote my Laravel Blade application with Laravel Inertia with a much more advanced and wise point of view. I saw how my past setbacks had transformed into mature lessons, which resulted in scalable, maintainable, and consistent code. The biggest lesson was not just to predict my core features better but also to realize that I could spend the first few weeks of creating an application with a prototype mindset. If I had dedicated the first phase of the application to experimenting with the features and gauging the risk and reward of certain features for myself, it would have allowed me to mess around with different major architectures without worrying about trashing the codebase, as it would get thrown out anyhow. I could've scheduled the delivery of my application at least twice as fast. It may seem counterintuitive to not jump straight into a project, but if I ever start a serious project again, creating a scrap prototypical project would be my go-to move. This mistake is quite similar to the previous one, but the lesson is a little different, so I will keep it. One of the biggest things engineers love to do is optimize their code, whether that be beautiful, elegant, or fast code. There were several times where I thought I had the best way to write my code, realized that I was following a bad practice, and rewrote my code into a cleaner format. One example was I rewrote all of my tests to a helper function method, mentioned here. Afterwards, I discovered a better way to write the form tests with a package. Another time I overengineered was writing my comment system in such a way that I could handle 2000+ comments easily and prevented any sort of N+1 query problems. However, even now, I barely have any comments on the application. Plus, I thought of more ways that I could improve the comment system. So, software is always evolving, and it is important to have your focus on the things that will have a business impact. The lesson is to understand that you don't need to have your codebase, features, or anything in your product fully fleshed out. No one notices cut corners. What really makes your application stand out is the core ideas and features it delivers. So, focus on delivering that and start polishing once you have users or feedback. Sometimes, I hold weekly recaps where I recognize things that I've done well and processes that I spent too much time on, even though I am a solo developer. I've noticed I started implementing many agile practices into my passion project, such as retros, postmortems, and sprint planning for the week. In the end, use whatever system you need to get insight on whether you are engineering the right amount. There are two schools of thought when it comes to validating your idea: create it and find out, or ask people and hear feedback. I think validation of the former is just more efficient for these sorts of passion projects. I feel that I should've spent less time determining if it was worthwhile for me to build this project to help others. I asked my friends around, and they had positive responses. Despite that, I still felt hesitant to work on this project. What I forgot was that I wanted to work on the project for myself. Even if no one else wanted to use the site to discover learning resources, I would still use this site. I can share quality resources that I use with the world. If I think the idea is valid for myself, then it is plenty valid for others. It may not be the best way to handle validity, but you cannot find any sort of closure in your ideas from others unless you believe in it yourself. It's like a marriage. It doesn't matter if your girl is the prettiest on the block; if you don't love her, the marriage will fail. And if you love her and no one else does, it doesn't matter. The marriage will still succeed. I didn't need to waste so much time contemplating if I made the right decision. Now, I just continue doing this for me. During the development of the site, I've faced burnout maybe 3 times. I realized that I started treating some of the side project like a job. There came a point where I had to write tests to make development faster. However, creating a large module for the codebase sometimes resulted in an entire week dedicated to writing tests for it. This was an absolute dread that killed a lot of motivation for the project. I sometimes forget that I am working on the computerscienceresources.com project for my personal enjoyment and don't need to force myself into torment. Realize when you are slowing down and starting to find processes mundane. I think that ThePrimeagen has great advice about burnout: it's when you start finding no joy in the work you do. To follow his advice, I've started balancing the work with experimental fun work alongside the mandatory tedious things. In addition, just switching work occasionally can spark more inspiration and interest again. I don't find unit testing, writing UI, or even debugging problems boring. But if I were to spend more than a few days on one problem, I would burn out real fast. So, stop motivating yourself by forcing yourself to get things done. That is being motivated by fear, focusing on the negative, which results in burnout. Instead, focus on the cool things that make software engineering fun and awesome. Focus on the positive side of completion, which results in fulfilling work. Experiment and swap around what you work on; then, naturally, you would discover your speed will increase as well. The biggest problem I've had and am still struggling with is being boldly proud and public with what I've built. Engineers see the holes in their designs, the faults, and all the problems that don't matter and are never seen by end users. But none of that matters. All big companies have released janky products. They proudly release their project, get feedback from their first customers, and continuously iterate from there. People release garbage all the time and slowly churn it into a mature product. I had much fear in being public with my site. I was worried about what other people would think and the criticisms I would face. However, it's been a few months since I've released the application without any advertising, not even much amongst my friends. The site has driven little traffic, which is to be expected. So, I have reached my goal: I have not received any criticisms of the site, as I have no one to receive criticisms from. But my goal is to help many people, not build this project in isolation. I've started the process of publicity with this article. There is a lot of good advice in this article that I am going to follow, such as publishing on popular sites like Product Hunt. People proudly release and market stupid and foul projects all the time. Some people have no shame and spam their awful project on Reddit and Discord. If I — with a potentially good project — don't even try to promote it out of introversion, how do I even stand a chance against all the newly released applications? Promotion is not a commodity; it is necessary. So, I hope that everyone can learn from the mistakes that I have made through the development of my site. Of course, some lessons can only be learned from doing these things yourself. But I know that if you have read through to the end of this article, then you are already a person with great wisdom. I hope you have the best of luck with your side projects, and if you have any advice or tips for me for promoting side projects, or mistakes that you've made, please share them in the comments. I'd love a discussion! Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Wanting to find more ways to learn software - Determining the quality of a resource, like a bootcamp - Sharing learning methods with others - Resource Posting Resources Editing Resources Filtering Resources Upvoting Resources Reviews - Posting Resources - Editing Resources - Filtering Resources - Upvoting Resources - Comment system - Posting Resources - Editing Resources - Filtering Resources - Upvoting Resources