SparkBridge

Inspiration

We kept noticing the same gap in everyday community life: people often need small, practical help — picking up groceries, figuring out a form, learning a basic tech skill, finding a ride, or getting a second pair of eyes on something — but asking for help can feel awkward, and the places where people currently ask are fragmented across group chats, social media, and word of mouth.

At the same time, many people want to help but don’t know where the need is. We wanted to build a bridge between those two sides: a simple, community-focused tool that makes small acts of help easier to request, discover, and follow through on. That idea became SparkBridge.

The hackathon prompt — “Who could this help, and how?” — pushed us to keep the project grounded. Instead of trying to solve everything, we focused on one meaningful problem: making everyday help requests visible, trustworthy, and easy to act on within a local community.

What it does

SparkBridge is a working web prototype that lets community members post small, time-bound help requests and lets others browse and offer help.

Core features in the prototype include:

Post a help request with a title, description, category, urgency, and preferred time window.

Browse open requests filtered by category and status.

Offer help / claim a request so the requester can see who is responding.

Track request status from open to matched to completed.

Simple profiles and credit notes so users can include context about what they can help with.

Accessible, low-friction UI designed for people who may not be technical.

The goal is not to replace existing community networks, but to give them a lightweight coordination layer. A neighbor, student, volunteer, or community organizer can quickly see: What is needed, who needs it, and how can I help?

Current limitations / incomplete features: in-app messaging, identity verification, moderation tools, and notifications are planned but not fully implemented in the prototype. We call these out clearly rather than presenting them as finished.

How we built it

We built SparkBridge as a web application using [Next.js/React], [Tailwind CSS], and [Supabase/Firebase/your backend]. We used [GitHub] for version control and [Vercel/Netlify/your host] for deployment.

At a high level, the app has three main parts:

Request creation and browsing — a form-based flow for posting help requests and a feed for discovering open ones.

Matching and status flow — users can offer help, and the request moves through clear states such as open, matched, and completed.

Data and auth layer — [describe your auth/database setup], with a simple schema for users, requests, and offers.

We used a lightweight ranking heuristic to keep the feed useful rather than chronological only. For the prototype, we kept the weights simple and explainable rather than optimizing for a “black box” match.

We also used [list libraries/APIs/AI tools]. AI assistance was used for [brainstorming / debugging / drafting copy / generating boilerplate], and all generated code was reviewed, adapted, and integrated by us. External libraries and resources are credited in the project README.

Challenges we ran into

Scoping a real-world problem into a hackathon-sized prototype. It was tempting to build messaging, maps, verification, and reputation all at once. We had to choose the smallest end-to-end flow that still demonstrated the core idea.

Designing the data model. Requests, users, offers, and status changes needed to stay simple enough to build quickly but flexible enough to extend later.

Trust and safety. A community help app raises privacy and safety questions. We addressed this in the prototype with clear status labels and limited public information, while noting that verification and moderation are future work.

Time and integration. Connecting the frontend, backend, and auth flow within the submission period required constant prioritization and testing.

Making the UI understandable. We wanted the app to feel approachable for non-technical users, so we prioritized clear labels, simple categories, and a short request flow over feature density.

Accomplishments that we're proud of

We built a working end-to-end prototype: a user can post a request, browse requests, offer help, and see status changes.

We kept the project focused on a clear real-world problem and a specific audience rather than trying to be a generic social platform.

We created a simple, accessible interface that demonstrates the idea quickly in a demo video.

We documented our stack, credits, and incomplete features so judges and future contributors can understand what is real and what is planned.

We turned an open-ended idea into a project we can keep improving after the hackathon.

What we learned

A small project that works well is more convincing than a large project that half-works. Scoping down made the demo stronger.

User-first design matters. The hardest part was not the code — it was making the flow obvious to someone seeing it for the first time.

Documentation is part of the build. Clear setup instructions, credits, and limitations make a prototype more credible.

AI tools are useful accelerators, but ownership matters. We learned to use them deliberately, review outputs, and clearly explain our own contributions.

Real-world problems are often coordination problems. Sometimes the missing piece is not a new technology but a clearer way for people to connect.

What's next for SparkBridge

Next steps include:

In-app messaging and notifications so requests and offers can be coordinated without leaving the app.

Identity verification and moderation tools to improve trust and safety.

Built With

• chatgpt
• figma
• next.js
• postgresql
• react
• vercel
• vscode