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.
