I Built HackForPinas to Make Philippine Hackathons Easier to Discover

In my previous article, I talked about Train Track, the transit app I built around Metro Manila's railway systems. This project started with a completely different problem. I kept thinking about how difficult it can be to discover hackathons and coding competitions. Not because they don't exist. They do. The problem is that they're scattered everywhere. A university might announce one. A government agency might host another. A private company might run one. A developer community might post another. And suddenly you're checking multiple websites just to figure out: What can I actually join? So I built HackForPinas. What is HackForPinas? HackForPinas is a free, public, and open-source directory for Philippine: Hackathons Coding challenges Technology competitions The idea is pretty straightforward: Make opportunities easier to discover. Events can be filtered by: Region Format Organizer type Status Organizers are categorized as: Government University Private Instead of browsing through unrelated websites, users can explore opportunities in one place. But the more I worked on it, the more I realized that the directory itself wasn't the hardest part. The data was. The Data Problem Imagine trying to collect hackathons from different websites. One might have an RSS feed. Another might use WordPress. Another might expose an API. Another might have an ordinary HTML page. And another might not have anything structured at all. So HackForPinas uses multiple scraping strategies: WordPress REST API RSS GDG Community Eventbrite HTML + Cheerio The scraper runs through a background endpoint and collects events from different Philippine technology sources. The interesting part wasn't: "Can I scrape a website?" It was: Can I turn information from completely different sources into one consistent dataset? That became a much more interesting engineering problem. I Didn't Want Anyone to Publish Directly There's another problem with a public directory. If anyone can submit an event, what stops someone from submitting spam? Or a malicious link? Or incorrect information? That's why I designed the submission flow around moderation. Submission ↓ Zod validation ↓ Security checks ↓ Rate limiting ↓ pending_review ↓ Admin review ↓ Approve / Reject ↓ Published A community submission doesn't automatically become a public event. It goes through review first. Security Is Part of the Architecture This project also forced me to think more seriously about security. There are several types of user-controlled input. The application therefore uses: Zod schema validation Open-redirect protection HTML sanitization API rate limiting Supabase Row Level Security Controlled admin workflows One of the interesting things I've learned about security is that the most important features aren't always visible. A user might immediately notice an animation. They probably won't notice that a malicious redirect was blocked. But the second one can matter much more. Building an Admin Workflow The admin panel became an important part of the application. Administrators can: Review submitted events Verify organizers Edit event information Approve submissions Reject submissions I also added an audit trail. The submissions_audit_log table records moderation activity such as: Who performed the action What action was performed When it happened That gives the platform a history of how submissions were handled. Making the Interface Less Boring I also wanted HackForPinas to feel different from a typical directory. So I experimented with several visual effects. There's a generative SVG mesh background. There's a retro split-flap animation. There's a letter glitch effect. There are animated counters. These don't make the scraper work better. But they make the product feel like an actual product rather than a database with a frontend attached to it. And honestly, that distinction matters to me. The Stack The project is built using: Next.js 16 React 19 Tailwind CSS v4 Supabase / PostgreSQL Motion Cheerio Zod Lucide React Iconify date-fns The interesting part is that the application combines automated data collection with user-generated submissions. That means the system has to deal with two very different sources of data: Machine-generated data and Human-generated data. Both can fail in different ways. What This Project Taught Me Train Track taught me to think about the user's journey. HackForPinas taught me to think about the system behind the interface. I started asking questions like: Where does this data come from? Can I trust it? What happens if the source changes? What happens if someone submits something malicious? Who gets permission to publish? How do I track administrative actions? What happens when automation fails? Those questions weren't necessarily part of my original idea. But they became some of the most valuable parts of building the project. Why I Wanted to Build This for the Philippines There's also a personal reason behind the project. I wanted to build something specifically around the Filipino technology community. Not another generic tutorial project. Not another clone. Something that could potentially help Filipino developers, students, designers, and technology enthusiasts find opportunities to participate and build things. That's what makes HackForPinas more meaningful to me than simply saying: "I built a Next.js website." The framework is just the implementation. The problem is the interesting part. What's Next? HackForPinas made me interested in building software around local problems. For the next project, I went in a completely different direction. Instead of hackathons and developer opportunities, I started thinking about something much more familiar: Filipino food. That's where Lutong Simmer comes in.