Source: Dev.to

Introduction

For the past year I’ve been working on a side project called computerscienceresources.com. I noticed there is no centralized location for the diverse range of computer‑science resources.

• GitHub “Awesome Lists” are static, hard to filter by community reviews, and quickly become outdated.
• Many pathways into various software fields are scattered and often hidden.
• Popular resources (e.g., Brilliant) get a lot of hype, but it’s hard to gauge teaching quality and engagement.

These three issues motivated me to build a site that:

1. Helps people find more ways to learn software.
2. Allows users to determine the quality of a resource (bootcamps, courses, etc.).
3. Enables sharing learning methods with others.

The lack of a centralized website led to computerscienceresources.com. This post isn’t a promotion; it’s a reflection on the lessons I’ve learned after a year of development—mistakes, pivots, and everything in between.

---

Choosing a Tech Stack

After reviewing several options, I settled on Laravel because:

• Strong emphasis on developer friendliness.
• Robust ecosystem and mature MVC architecture.

I also evaluated:

• Supabase
• Phoenix (Elixir)
• Node.js
• .NET framework

Laravel’s ecosystem simply felt the strongest for the work I wanted to do.

Note: Some frameworks are “sexier” than others. Using PHP/Laravel may raise eyebrows in 2025—interviewers often prefer Node.js, Spring Boot, Django, or ASP.NET Core. I’ve had interviewers question my choice of PHP.

Nevertheless, I prioritized getting the application published over flashiness. Laravel’s starter kit let me prototype quickly, and I became proficient with the MVC pattern—skills that transfer to any framework.

Takeaway: Recruiters may not recognize that proficiency with one framework translates to others (e.g., moving from Laravel to Django). Choose a stack that serves your project’s goals—practicality or flashiness.

---

Defining the MVP

When you plan a long‑term project, start by defining the Minimum Viable Product (MVP). I created a list of top features and split them into vital and nice‑to‑have categories.

Core (vital) features

Nice‑to‑have features

• Advanced analytics
• Social sharing integrations
• Personalized recommendation engine

---

What Went Wrong

1. Under‑estimating effort – I treated the multistep form (saving to local storage) as trivial, building it with jQuery. The feature ballooned, consuming weeks that should have been spent on core MVP functionality.

2. Over‑engineering early – I spent months on a Laravel + Blade prototype with messy code, still missing several core features.

3. Complex “nice‑to‑have” became a distraction – Building a nested Reddit‑style comment system turned into a major undertaking, even though it wasn’t essential for launch.

4. Architecture churn – I eventually rewrote the app using Laravel Inertia after realizing the initial approach was unsustainable.

---

Key Lessons

1. Predict feature complexity – Spend time estimating effort before committing.
2. Prototype first – Use the first few weeks to experiment with different architectures and gauge risk/reward. Throw away the prototype code; it’s a learning investment.
3. Separate MVP from polish – Focus on delivering the smallest possible core feature set before adding sophisticated UI/UX touches.
4. Accept that flashiness isn’t always valuable – Recruiters may favor popular stacks, but delivering a solid product matters more.

If I start another serious project, I’ll:

• Allocate an initial “prototype” phase to test ideas without fear of breaking the codebase.
• Keep the MVP scope tight and measurable.
• Reserve “nice‑to‑have” features for post‑launch sprints.

---

Bottom line: A clear MVP, realistic feature estimates, and a willingness to prototype aggressively can halve delivery time and produce cleaner, more maintainable code.

A Prototypical Project: My Go‑to Move

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.

---

Optimizing Code

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.

  • Example: I rewrote all of my tests into a helper‑function method (mentioned here). Afterwards, I discovered a better way to write the form tests with a package.

• Another time I over‑engineered was writing my comment system so that it could handle 2,000+ comments easily and prevented any sort of N+1 query problems.

  • In reality, I barely have any comments on the application, and I kept thinking of more ways to improve the comment system.

Lesson: You don’t need to have your codebase, features, or product fully fleshed out. No one notices cut corners. What really makes your application stand out are the core ideas and features it delivers. Focus on delivering those, and polish once you have users or feedback.

---

Weekly Recaps & Agile Practices

Even as a solo developer, I hold weekly recaps where I recognize things I’ve done well and processes that consumed too much time. I’ve started implementing many agile practices into my passion project, such as:

• Retrospectives
• Post‑mortems
• Sprint planning for the week

In the end, use whatever system you need to get insight on whether you are engineering the right amount.

---

Validating the Idea

There are two schools of thought when it comes to validating an idea:

1. Create it and find out
2. Ask people and hear feedback

For passion projects, I think the former is more efficient. I should’ve spent less time determining if it was worthwhile to build this project to help others. I asked my friends around, and they gave positive responses, yet I still felt hesitant.

What I forgot: 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 it. I can share quality resources that I use with the world. If the idea is valid for me, it’s plenty valid for others.

It may not be the best way to handle validity, but you cannot find closure in your ideas from others unless you believe in them yourself. It’s like a marriage: it doesn’t matter if your partner is the prettiest on the block; if you don’t love them, the marriage will fail. And if you love them and no one else does, the marriage will still succeed. I didn’t need to waste so much time contemplating whether I made the right decision. Now, I just continue doing this for me.

---

Burnout & Motivation

During development of the site, I’ve faced burnout maybe three times. I realized I started treating the side project like a job. At one point I had to write tests to make development faster, but creating a large module sometimes resulted in an entire week dedicated to writing tests for it. That dread killed a lot of motivation.

• Realize when you are slowing down and finding processes mundane.
• ThePrimeagen’s advice on burnout: it’s when you start finding no joy in the work you do.

To follow his advice, I’ve started balancing mandatory tedious tasks with experimental, fun work. Switching tasks occasionally sparks inspiration again. I don’t find unit testing, writing UI, or debugging boring, but if I spend more than a few days on one problem, I burn out fast.

Takeaway:
Stop motivating yourself by forcing things out of fear. That’s motivation driven by negativity, which leads to burnout. Instead, focus on the cool aspects that make software engineering fun and awesome. Emphasize the positive side of completion, experiment, and swap what you work on. Naturally, your speed will increase.

---

Being Public with My Work

The biggest problem I’ve had—and am still struggling with—is being boldly proud and public with what I’ve built. Engineers see holes in their designs, faults, and problems that don’t matter to end users. Yet none of that matters.

All big companies release janky products. They proudly launch, get feedback from early customers, and continuously iterate. People release garbage all the time and slowly churn it into a mature product.

I was afraid to be public with my site. I worried about what others would think and the criticisms I would face. However, it’s been a few months since I 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, because 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 the article that I will follow, such as publishing on popular sites like Product Hunt.

People proudly release and market “stupid” and “foul” projects all the time. Some have no shame and spam their awful projects on Reddit and Discord. If I— with a potentially good project—don’t even try to promote it, I’m missing the chance to get real feedback and improve.

---

Closing Thoughts

• Focus on core value, not perfection.
• Iterate quickly and learn from real users.
• Balance work and fun to avoid burnout.
• Share publicly; feedback is essential for growth.

By keeping these principles in mind, I can continue building computerscienceresources.com (or any side project) in a sustainable, enjoyable, and impactful way.

Conclusion

“e 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 wish you the best of luck with your side projects. If you have any advice or tips for me on promoting side projects, or mistakes that you’ve made, please share them in the comments. I’d love a discussion!