-
-
Welcome Screen
-
Create Account form
-
User details input
-
Neighborhood selection list
-
Notification permission request screen
-
Brief notes for new users
-
Empty Feed state
-
Home Feed
-
Chat Interaction View
-
Add New Post (Need/offer)
-
Successfully added New Post
-
Conversation List
-
Settings View where u can update your neighborhood location
NeighborBoard: About the project
HackSocial 2026 · Lifestyle Hacks
Inspiration
Most of the help we need day to day is already nearby salt for dinner, a ride across campus, someone who can tutor math but we still ask Facebook groups or strangers online. We wanted something smaller and more human: your neighborhood as a resource network, not another global feed chasing engagement.
NeighborBoard was inspired by that gap. If you already live near people who can help, the app should just make it easy to ask, offer, and talk.
What it does
NeighborBoard is a hyperlocal needs & offers board:
- Pick your neighborhood and join a feed scoped only to that place
- Post a Need or Offer in Food, Transport, Time & Skills, or Stuff
- Neighbors respond with “I can help” / “I’d like this”, which opens a direct chat tied to the post
- Manage your posts, report bad content (auto-hide at 3 reports), and get push notifications for new messages
No algorithmic ranking. No ads. Just the block next door.
How we built it
| Layer | Stack |
|---|---|
| App | Flutter |
| Auth | Firebase Auth (Apple, Google, phone, email) |
| Data | Cloud Firestore (real-time streams) |
| Media | Firebase Storage |
| Push | FCM + local notifications |
| Nav / state | go_router · flutter_bloc |
We designed around a simple model: neighborhoods → users → posts → conversations/messages. Author and neighborhood fields are denormalized onto posts so the feed stays one query. Chat is 1:1 and always linked back to the originating post. An admin seed path loads Boston neighborhoods so demos aren’t blocked by an empty picker.
Challenges we ran into
- Trust vs. speed: We wanted real mutual aid without building a full moderation product. Reporting + auto-hide at 3 distinct reporters was the compromise.
- Firebase “which database?” pain — Emulator vs cloud and multiple Firestore DBs made data look “missing” until we standardized on
(default)and a clear boot log. - iOS push: FCM tokens won’t mint without a real APNs registration path; simulators and incomplete AppDelegate setup burned time until we fixed remote-notification registration and retry logic.
- Chat UX under navigation: Opening/closing threads while async work ran caused classic Flutter
dispose/context.readcrashes; we fixed that by caching services before teardown. - Demo readiness: An empty neighborhoods collection breaks onboarding. The Admin “Seed Boston” flow became a must-have for judging day.
What we learned
- Place is a feature. Scoping by neighborhood makes the product feel safer and more useful than a city-wide dump of posts.
- Denormalize on purpose. Firestore isn’t SQL: storing display names on posts keeps the UI fast and simple.
- Polish the path judges will take. Seed data, two-account chat, and a short dual-device demo matter as much as new features.
- Mobile push is part of the product. “It works on Android / in the emulator” isn’t enough if iOS never gets an APNs token.
What’s next
Tighter security rules, better notification coverage (not just chat), and optional light location hints for neighborhood suggestions without turning NeighborBoard into another noisy social network.
Log in or sign up for Devpost to join the conversation.