Inspiration
Arriving in a new city often means searching fragmented social feeds, event pages, and group chats without knowing which community genuinely fits your dates, interests, budget, accessibility needs, or preferred atmosphere.
PsyNet was inspired by a simple question: how can people find a community that genuinely feels right when they are traveling, relocating, or entering a new creative scene? We wanted to replace scattered, uncertain searching with a trusted guide that understands both practical constraints and human preferences.
What it does
PsyNet's Tribe Scout turns a natural-language request into a structured community search. GPT-5.6 extracts only the constraints the user actually supplied. PsyNet retrieves matching community records, then GPT-5.6 ranks only those retrieved identifiers and explains the evidence, trade-offs, and safety caveats behind each match. The user can open a recommended community and take a clearly labeled next action.
If a location is missing, Tribe Scout asks a clarification question. If there is no grounded result, it says so. If Neon is unavailable, a stable demo catalog is explicitly labeled. A model timeout, quota error, or invalid response is surfaced as an error and never replaced with a fabricated recommendation.
How we built it
We built PsyNet with Next.js 16, React 19, TypeScript, Tailwind CSS, Neon Postgres, Vercel Functions, the official OpenAI JavaScript SDK, the Responses API, and GPT-5.6.
Tribe Scout uses a grounded two-stage AI pipeline:
- A strict Structured Output extracts location, dates, interests, budget, accessibility needs, and preferred vibe.
- PsyNet code retrieves and limits candidate communities.
- A second strict Structured Output ranks only the supplied candidate IDs.
- Local validation rejects unknown IDs, duplicates, invalid scores, and malformed output before anything reaches the UI.
Both model calls are server-side, use the Responses API, set store: false, and send only the fields needed for the recommendation.
Codex audited the pre-existing prototype, translated the requirements into a one-week backlog, created quality gates, implemented the two grounded GPT-5.6 boundaries, extracted testable data and orchestration modules, added degraded-mode and error behavior, improved the Tribe Scout interface, and maintained a dated evidence log. Product scope, safety boundaries, the hybrid rollout, and the decision not to fake persistence remained explicit human decisions.
Challenges we ran into
The hardest challenge was making AI recommendations useful without allowing the model to invent communities or silently hide failures. We separated retrieval from ranking, restricted GPT-5.6 to known candidate IDs, and validated every structured response locally. We also designed distinct states for missing information, empty results, model timeouts, quota errors, invalid output, unavailable persistence, and database degradation.
Another challenge was extending an existing prototype during a short build window while clearly separating pre-event work from new work. We documented that boundary and kept a dated development log so the submission remains transparent and verifiable.
Accomplishments that we're proud of
- Built an end-to-end, explainable community-discovery journey instead of a generic chatbot.
- Grounded every recommendation in retrieved community data and rejected unknown or duplicate IDs.
- Added evidence, trade-offs, provenance, and safety notes so users can understand each match.
- Created honest degraded and error modes that never disguise a failure as a successful AI recommendation.
- Added automated evaluation and a production-ready server-side integration with OpenAI and Neon.
- Preserved a clear record of what existed before Build Week and what was built during it.
What we learned
We learned that trustworthy AI experiences depend as much on boundaries and failure behavior as on model quality. Structured Outputs made the model predictable, but application-level retrieval, validation, and explicit UI states were still essential. We also learned that explanations are most useful when they expose concrete evidence and trade-offs rather than simply presenting a confidence score.
Finally, we learned that Codex is most effective as an engineering collaborator when the product constraints are explicit: it accelerated auditing, implementation, testing, and documentation while leaving product and safety decisions visible and human-owned.
What existed before Build Week
The application shell, visual language, static product screens, initial DynamoDB routes, and chat UI existed before the event. The GPT-5.6 intent extraction and grounded ranking, validators, Tribe Scout result experience, degraded-mode behavior, automated evaluation, and submission evidence were created during the official period.
Built With
- codex
- google-places
- gpt-5.6
- neon
- next.js
- node.js
- open-meteo
- openai-api
- openai-javascript-sdk
- playwright
- postgresql
- react
- responses-api
- structured-outputs
- tailwind-css
- typescript
- vercel
- vercel-functions
- webrtc
Log in or sign up for Devpost to join the conversation.