Why I Build Projects No One Asks For (And Why You Should Too)

 Hi, I’m Jesse Calay, a computer science student from the Philippines. I started coding a few years ago because I liked the idea of being able to build something from nothing. At first, it was all schoolwork, basic Python scripts and C programs that only ran properly if the stars aligned. Eventually, once I got more comfortable, I began to branch out and make things that were outside the curriculum. Things no one asked for, no one graded, and honestly, things no one really used except me.

But here’s the truth. Those side projects, the ones that didn’t matter to anyone but me, are the reason I’ve grown so much as a developer.

One of the first things I ever built outside of class was a barangay alert app. It didn’t have a real backend and I made the interface in plain HTML and CSS, but I wanted to try creating a tool for something I saw every day. During typhoon season, people in my community often relied on Viber group chats, forwarded messages, or word-of-mouth for updates. My idea was to create a basic notification system that could be updated by a central source and broadcast to a list of subscribers.

The project never launched publicly. I couldn’t solve the SMS integration at the time and I didn’t know anything about APIs. But what it taught me was priceless. I had to figure out user authentication, responsive design, even how to make content available offline for people with weak internet. Those lessons stuck with me way more than anything I learned from filling in blanks on an exam.

Since then, I’ve made a bunch of small tools and utilities. A budgeting tool for sari-sari store owners, a browser extension that blocks toxic phrases from online comments, and a chatbot for my cousins that tells corny Tagalog jokes. None of these were planned, funded, or requested. I built them because I had an idea, and I wanted to see if I could make it work.

People often think that to be a serious developer, you need to work on big frameworks or contribute to major open source libraries. Those are great goals, but I’ve found so much value in doing small, imperfect projects that solve real (or even ridiculous) problems. It forces you to wear every hat. You become the designer, the engineer, the tester, the product manager, and sometimes even the customer.

I also learned the importance of finishing. That’s the hardest part. It’s easy to start something and leave it half-built in a folder. It takes real discipline to say, “This is done enough to use,” even if it’s not perfect. When I built a local election tracker during a past election, I spent so much time tweaking the design that I almost missed launching it in time. Since then, I’ve focused more on function first, polish later.

Another thing I try to do now is document everything. Even if the project is small, I’ll write a short README, upload screenshots, and push the code to GitHub. I want to build habits that make my future work more understandable and maintainable. I also try to write blog entries like this one after I finish something, partly to keep track of what I’ve learned and partly to show that I’m serious about growing.

These days, I split my time between school projects and side projects. Some weeks I focus more on algorithms and data structures for class. Other weeks I’m knee-deep in JavaScript debugging because I had a random idea at 2 a.m. and couldn’t sleep until I got it working. Both types of work matter. But there’s something special about building without limits, without rubrics, and without pressure to impress anyone.

I’ve come to believe that the best developers are not the ones who memorize the most syntax or ace every coding exam. They’re the ones who keep making things. Who stay curious. Who get a weird idea, follow it through, and learn from whatever happens next.

I hope this encourages someone out there to start their own little project, even if it seems silly. You don’t need a team, a budget, or a professor’s approval. You just need time, curiosity, and the willingness to try. I’m still figuring things out myself, but every unfinished repo, broken build, and working prototype teaches me something.

My name is Jesse Calay, and I build things that no one asks for. And I plan to keep doing it, because that’s how I learn best.