-
-
Basic Design
-
static weather later changed to dynamic via Open-Meteo
-
earlier firebase data structure
-
User Profile (preferences,tag,budget)
-
making active in realtime
-
Notification system
-
Plan and history section for keeping track
-
dual way ping later discarded(with 1 guy location share it will work)
-
Final Firestore DB
-
static venue (fallback)
-
Dynamic venue via groq
-
Vercel Deployment (frontend)
-
Render Deployment (Backend)
Inspiration
Ping AI started with a simple frustration: making plans with a friend often takes more effort than the meetup itself. “Are you free?” becomes “When?” then “Where?” and eventually the plan disappears.
I wanted to turn that long conversation into a lightweight, consent-based action: tell your friends you are available, send a Ping, and find a reasonable place to meet.
The project is also dedicated to a friend I lost. While building Ping AI, the idea became more personal. If it helps even one person reach out to someone they care about, it has achieved something meaningful.
What it does
Ping AI helps friends coordinate spontaneous meetups.
A user can:
- Sign in with Google.
- Add friends using an email address or Ping handle.
- Turn on Available to meet and choose an activity, travel distance, and availability duration.
- Share their location only after explicitly opting in.
- See which friends are currently available.
- Send a Ping instead of starting a long conversation.
- Respond with Yes, Later, or Not today.
- Review AI-generated meetup suggestions.
- Confirm a final plan.
- Open the location in Google Maps.
- Share the plan through WhatsApp or copy it to the clipboard.
- View notifications, request history, and saved meetup plans.
The core loop is:
Available → Ping → Respond → Choose a place → Confirm → Meet
How I built it
Ping AI is built with React and Vite on the frontend, Firebase Authentication for Google sign-in, and Cloud Firestore for application data.
Firestore stores:
- User profiles and Ping handles
- Friend requests and friendships
- Availability state and expiry times
- Ping responses and notifications
- Saved meetup plans
- Request and meetup history
A Node.js and Express API handles venue recommendations. The recommendation service sends the two users’ location context, activity, travel preferences, and budget to Groq. The AI returns several possible venues, while the application validates and formats the response before displaying it.
The app also includes a fallback dataset so the demo remains usable if the AI request fails or reaches a rate limit. This keeps AI helpful without making the entire product depend on one API call.
The frontend is deployed on Vercel, Firebase provides authentication and Firestore, and the Express recommendation API is deployed separately.
I used Codex and GPT-5.6 during development to help scaffold components and API routes, debug Firestore flows, shape the recommendation prompt, and reason through edge cases such as declined Pings, expired availability, plan confirmation, and refresh persistence. The product direction and design decisions were mine.
Challenges
The biggest challenge was scope. The original idea could easily expand into a full social network with live maps, push notifications, richer venue data, and real-time routing. With limited time, I focused on making one complete interaction reliable:
- Opt into availability.
- Find an available friend.
- Send and respond to a Ping.
- Generate meetup suggestions.
- Confirm and save a plan.
Another challenge was making location sharing feel safe. Location is not continuously requested. It is only requested when the user explicitly enables availability, and the availability record expires after the selected duration.
I also had to handle unreliable external services. AI responses can be incomplete, APIs can be rate-limited, and venue suggestions may not contain every field. A service-layer parser and local fallback allow the prototype to continue working instead of failing completely.
What I learned
I learned that a focused product loop is more convincing than a large collection of unfinished features. The most important decisions were not about adding more screens, but about defining when information should be shared and when a notification should be sent.
I also learned to use AI selectively: for repetitive scaffolding, debugging, and exploring edge cases, while keeping product decisions, privacy choices, and user experience direction under my control.
What's next
The prototype is ready to demonstrate the core experience. The next production improvements would be:
- Verify Firebase ID tokens on the Express backend instead of relying on prototype request context.
- Add server-side authorization checks and stricter Firestore validation.
- Add rate limiting and abuse protection for friend requests, Pings, and AI recommendations.
- Use a geospatial venue provider with verified addresses, opening hours, ratings, and coordinates.
- Replace in-app notifications with push notifications.
- Improve travel-time estimates using routing data rather than approximate distances.
- Add better offline handling and retry states.
- Add privacy controls for location history and automatic data expiry.
- Add optional meetup memories, such as photos or notes, after a confirmed meetup.
- Support group Pings for three or more friends, with shared availability and a meetup plan that works for the group.
- Add group planning controls so participants can vote on activities and venues.
- Support online meetups for friends who cannot meet physically, including game sessions, watch parties, study sessions, and voice/video calls.
- Add activity-specific planning for gamers, such as choosing a game, platform, party size, and preferred play time.
Built With
- ai
- auth
- collaboration
- events
- express.js
- firebase
- firestore
- friends
- genai
- gps
- hackathon
- javascript
- maps
- meetup
- node.js
- planning
- privacy
- react
- realtime
- recommendations
- social
- travel
- vite
- webapp
Log in or sign up for Devpost to join the conversation.