How we built it

Flutter and Dart for the app itself, so one codebase runs on both Android and iOS. Firebase Firestore as the backend, since a campus community app is fundamentally about real-time — chat messages, likes, replies showing up instantly for everyone. We didn't design the whole thing upfront and then build it; it was much more iterative than that. We'd build a piece, actually use it, find what felt wrong, and fix it before moving to the next thing. The Communities feature alone went through a few real redesigns before it landed — the first version had communities and posting mixed together in a way that didn't feel natural, so we pulled them apart: a community's own profile page, a real-time Room for its members to actually talk, and posting that happens from the main feed by tagging a community, not from a separate button buried on its page. For push notifications, we used a Cloudflare Worker instead of Firebase's own Cloud Functions — a deliberate call to keep the project on Firebase's free tier while still getting real server-side notification delivery.

Challenges we ran into

The honest one: Firestore has this quirk where a query combining a filter and a sort needs an index created for it manually, and if you forget, it doesn't throw an error you'd notice — it just quietly returns nothing. We hit this more than once, and each time it looked like a feature was just broken for no reason until we found the actual missing piece. We also had a real bug where likes and comments on posts made inside a community weren't giving people any Clout at all, because the code was still checking an old field name from before communities existed. It was working exactly as written — just written for a version of the app that didn't exist anymore. Outside of code, just getting comfortable with the deploy pipeline itself was its own challenge — release builds behave differently from what you test day to day, and small things like Android's newer splash screen system needing a completely different image setup than we expected caught us off guard.

Accomplishments that we're proud of

The feed doesn't just show the newest posts — it actually pays attention to who you follow, what you've shown interest in, who you've actually engaged with before, and even how long you pause on something while scrolling. That's a real ranking system, not a shortcut. We're also proud of how alive the Communities feel — real-time threaded replies, a reputation system that grows with genuine participation, and milestones that unlock on their own as a community actually grows, not because an admin clicked a button. And honestly, we're proud of catching as many of our own bugs as we did before real people ran into them.

What we learned

That something working in testing isn't the same as something being ready for real people. A few times we had to go back and specifically check: does this rule exist where it needs to, does this index actually exist, does this work outside of the one exact way we just tested it. We also learned to be honest about scope — there were a couple of things we chose not to fake, like a "members online now" counter with no real activity tracking behind it, because a fake number is worse than no number at all.

What's next for Edulink

Right now Edulink is built specifically around one university. The bigger plan has always been to open it up to other schools without losing what makes it feel personal to any one campus — every student should still feel like their feed and their communities are actually theirs, not lost in a much bigger platform. Beyond that, a real events system with RSVPs is the next big piece we deliberately held off on tonight so we could give it proper attention on its own, rather than squeeze in a shallow version of it.

Built With

Share this project:

Updates

Submission history