WEB · SOCIAL COMPUTING · 2025
CoQuest — Spontaneous Social Coordination
A real-time mobile platform that turns small pockets of free time into lightweight opportunities for in-person connection.
Built with React Native and Firebase, CoQuest lets students broadcast and join short-lived activities through a shared campus map and trusted social circles.
- Role
- Product & Engineering Team
- Team
- 4 people
- Pilot
- 3 days
- Stack
- React Native + Firebase
- Jamba run · now
- Study session · 20 min
- Morning run · 8:30
- Board game night · 7pm
Choose a few options and post to see a quest appear on the map.
Pilot participants
Quests created
Live deployment
Avg. quest creation, after iteration
Quests from 3 highly active hostsUneven participation
Results reflect a small Stanford pilot and should be interpreted as formative product evidence.
Overview
The space between a group chat and a calendar invite
Formal planning
- Calendar invites
- Scheduled events
- Detailed group chats
- High commitment
- High coordination cost
- Works for planned events
The missing middle
- “I have 30 minutes”
- “Anyone nearby?”
- “Thinking about getting food”
- Temporary availability
- Low commitment
- Usually invisible to acquaintances
CoQuest
- Short-lived quest signals
- Visible
- Time-boxed
- Easy to join
- Easy to ignore
CoQuest was designed for the missing middle: casual coordination among people who may not be close enough to directly message, but aren't strangers either.
Interaction
Quests as signals
Quick Jamba run
Tresidder · Starts in 5 min
Shared with: Dorm friends
2 joining
- What
- Short activity title
- Where
- Map-linked location
- When
- Immediate or near-future time
- Who
- Selected audience
- Expiration
- Automatically disappears when no longer relevant
A quest is not a formal event. It is a temporary signal of availability.
- Create
- Broadcast
- Discover
- Join
- Meet
- Expire
Experience
A walk through the product
Discover
Discover nearby activity
- Quests appear as interactive map markers
- Location makes the opportunity feel immediate
- Users can browse without committing
- Hosted and available quests are visually differentiated
Browse
Browse intentionally
- Upcoming, hosted, and past views
- A filtered list for users who prefer structured browsing
- Complements the ambient map experience
Broadcast
Broadcast a quest
- Minimal required input
- Optional description
- Default near-term timing
- Audience selection
- Location lookup
Coordinate
Coordinate within trusted circles
- Users create private audience groups
- Groups act as distribution filters
- Group membership is not publicly displayed
- Quests may target a selected circle rather than the entire campus
Behavior
Designing for low-pressure participation
Lower activation energy
- Quest titles limited to about 40 characters
- Descriptions optional
- Time defaults toward the immediate future
- Creation reduced to a few taps
- Average creation time fell from about 18 seconds to under 7
Support lightweight presence
- Users can open the app simply to see what is happening
- Browsing is treated as valid participation
- Map activity creates ambient social awareness
- Joining does not require a conversation thread
Make silence an acceptable no
- Quests expire automatically
- Users do not need to reject an invitation
- No public consequence for ignoring a quest
- Social groups remain private
Before iteration
~18 sec
- More fields
- Greater hesitation
After iteration
<7 sec
- Fewer required inputs
- Faster posting
Describes an observed pilot usability improvement, not a controlled large-scale experiment.
Architecture
Built for real-time, location-aware coordination
Core data flow
- React Native client
- Firebase Authentication
- Firestore
- Real-time listeners
- Reactive map & dashboard updates
Location lookup
- User-selected location
- Coordinates
- LocationIQ reverse geocoding
- Human-readable location
- Quest document
- Client interface
- Firebase service
- Real-time event
- External service
Application areas
- Authentication
- Map
- Dashboard
- Quest creation
- Profile
- Groups
- Settings
Reusable components
- Quest card
- Quest detail
- Map pin
- Group selector
What happens in real time
What happens when someone posts?
- Host device
Presses Post — a quest document is created in Firestore
- Firestore
Time, location, host, audience, image, and description are stored
- Firestore
The quest's expiration time is calculated
- Host device
The quest ID is added to the host's relevant quest collections
- Audience profiles
The selected audience's feeds are updated
- Listener
Firestore listeners receive the change
- Map/dashboard
The map and dashboard update without a manual refresh
- Map/dashboard
As people join, the attendee list and RSVP state update
What happens when someone joins?
- Host device
A user joins the quest
- Firestore
A successful write is confirmed
- Firestore
The attendee list updates
- Listener
Joined-quest state updates
- Map/dashboard
The UI confirms the RSVP
The interface waits for a successful write before confirming a join, to avoid inconsistent RSVP state.
Data model
Users
- SUNet identifier
- First and last name
- Groups
- Displayed quests
- Hosted quests
- Joined quests
Quests
- Name
- Description
- Start time
- End time
- Host
- Audience group
- Location
- Photo
- Attendees
Groups
- Name
- Owner
- Member handles
- Created timestamp
- Updated timestamp
- User hosts Quest
- User joins Quest
- User owns Group
- Group distributes Quest
- Group contains Users
Pilot
Three days in the wild
Day 1
Early users create the first quests.
Visible activity establishes the initial norm.
Day 2
Other participants begin replicating lightweight quest formats.
Users open the app to see what is happening even without joining.
Day 3
The app develops a shared rhythm of casual activity.
Participants use it for study sessions, food runs, exercise, and social events.
| Pilot measure | Observation |
|---|---|
| Participants | Approximately 10 |
| Deployment | 3 days |
| Quests created | 67 |
| Quests created by three highly active hosts | 49 |
| Quest-creation time after iteration | Under 7 seconds |
| Quest-creation time before iteration | Approximately 18 seconds |
- Participants
- Approximately 10
- Deployment
- 3 days
- Quests created
- 67
- Quests created by three highly active hosts
- 49
- Quest-creation time after iteration
- Under 7 seconds
- Quest-creation time before iteration
- Approximately 18 seconds
Participation was highly uneven, which matched the expected contribution-pyramid pattern.
Participation pyramid
Initiators
A small number of users created much of the available activity — three highly active hosts produced 49 of the 67 quests.
Participants
Some users joined quests without frequently hosting.
Browsers
Some users opened the app and observed activity without posting or joining — five users primarily lurked but returned to the app multiple times during the pilot.
Block width reflects roughly how many participants fell into each role, not their value to the pilot.
Passive viewing was not necessarily failed engagement. Ambient awareness was part of the intended experience.
Participation roles appeared fluid and changed with timing and availability.
Social computing theory in practice
The pilot cohort was small and socially connected, so these observations are read as directional, not conclusive.
Contribution pyramid
Theory
A small number of users will initiate most activity.
Observed
A few highly active hosts generated much of the pilot's content.
Descriptive norms
Theory
Visible behavior makes similar behavior feel acceptable.
Observed
Once early quests appeared, other users adopted similar casual formats.
Ambient social awareness
Theory
People benefit from knowing who is available without directly coordinating.
Observed
Users opened the map simply to see what was happening.
Strength of weak ties
Theory
Lightweight signals can create opportunities beyond a person's closest relationships.
Observed
Participants reported connecting beyond their usual friend groups.
Trust
Spontaneity without default oversharing
| Design concern | Product response |
|---|---|
| Unwanted location exposure | Users deliberately select a location and audience |
| Pressure from group membership | Group membership is not publicly visible |
| Unknown users | Access restricted to Stanford-affiliated email accounts |
| Formal rejection anxiety | Ignoring a quest requires no explicit response |
| Stale location or activity data | Quests expire after their time window |
| Oversharing to the whole campus | Users can target custom social circles |
| Inconsistent RSVP state | UI confirms joins after successful backend writes |
- Unwanted location exposure
- Users deliberately select a location and audience
- Pressure from group membership
- Group membership is not publicly visible
- Unknown users
- Access restricted to Stanford-affiliated email accounts
- Formal rejection anxiety
- Ignoring a quest requires no explicit response
- Stale location or activity data
- Quests expire after their time window
- Oversharing to the whole campus
- Users can target custom social circles
- Inconsistent RSVP state
- UI confirms joins after successful backend writes
These are design safeguards and trust mechanisms, not a claim that the product is completely safe.
My role
My contributions
CoQuest was built by a four-person team. The contributions below describe what I personally worked on within that team, not sole ownership of the project.
Product definition
- Helped translate the social-coordination problem into a concrete quest-based interaction
- Contributed to defining the low-friction posting and joining experience
Mobile engineering
- Contributed to the React Native application and its reusable screen/component structure
- Helped connect interface states to Firebase-backed data
Real-time systems
- Supported Firestore data flows for quests, users, groups, and RSVP state
- Helped manage asynchronous writes and reactive updates
Location experience
- Contributed to map-based quest discovery and human-readable location handling
Pilot and iteration
- Helped test the product with a live student cohort
- Used observed behavior to improve the creation flow and interpret participation patterns
Reflection
What worked — and what became harder
Tension 1
Low friction encouraged posting, but activity remained uneven
Finding
Three highly active hosts generated 49 of the 67 quests.
Implication
The product depended heavily on a small number of initiators.
Tension 2
Ephemerality reduced pressure, but silence could feel like rejection
Finding
A quest disappearing without anyone joining could make hosts feel as though they were “shouting into the void.”
Implication
Future versions need encouragement and feedback without introducing vanity metrics.
Tension 3
Ambient awareness created value even without joining
Finding
Some participants repeatedly opened the app simply to observe nearby activity.
Implication
Success should not be measured only through posts and RSVPs.
Tension 4
Local critical mass mattered
Finding
The experience became useful when enough activity was visible within both individual friend groups and the broader cohort.
Implication
Scaling requires community-level seeding, not only user acquisition.
What we would test next
- Expand from approximately 10 users to larger cohorts
- Test whether the feed remains useful at 100 or more users
- Determine how many active hosts are needed per social circle
- Explore feed-ranking and density controls
- Test encouragement prompts for hosts whose quests receive no response
- Preserve low-pressure participation without gamification
- Investigate stronger location and audience privacy controls
- Test whether group-based critical mass can be built independently
- Measure real-world meetups separately from quest creation
- Study whether engagement persists beyond initial novelty
- Compare map-first and dashboard-first discovery behavior
Tech & topics
- React Native
- TypeScript
- Firebase Authentication
- Firestore
- Real-Time Listeners
- LocationIQ
- Geolocation
- Mobile UI Design
- Social Computing
- Product Experimentation