VYBE
A ride that knows where it's going, who's in it, and what the car is in the mood for.
- Built for
- VYBE (Emmanuel's own product)
- Engagement
- AI passenger experience platform
- My role
- Product discovery, requirements, solution architecture, build and demo
- Source
- vybe-app-blue.vercel.app
vybe-app-blue.vercel.app
Status at time of writing
Stamped from the live build, not from the plan.
| Component | Status | Note |
|---|---|---|
| Product site + VYBE Voice | Live Deployed on Vercel, Variation 5 design locked. | Deployed on Vercel, Variation 5 design locked. |
| ElevenLabs Scribe + TTS | Live Reported connected by the production health endpoint. | Reported connected by the production health endpoint. |
| Supabase | Live Auth, rides, participants, saved VYBEs. | Auth, rides, participants, saved VYBEs. |
| Google Places / Routes + generative model | Not activated Wired server-side, awaiting production credentials. Route-aware generation is off in production. | Wired server-side, awaiting production credentials. Route-aware generation is off in production. |
1Business problem
Passengers bounce between maps, music apps, restaurant searches and group chats. None of those tools know the ride: where the car is going, how long it takes, who is in it, or the mood.
The result is a trip spent negotiating apps instead of sharing an experience, and suggestions that don't fit the time or place.
2Discovery
- 2.1What decisions do people actually make in a car? Four keep recurring: what to hear, what to eat, what to see, what to do.
- 2.2What context changes the right answer? Destination, trip length, number of passengers and mood. Those became the ride's first-class inputs.
- 2.3Who owns the ride? A shared ride has to reflect the group, not whichever phone opened the app.
3Requirements
| R-01 | Ride context model: destination, trip length (15 min / 30–60 min / 1–3 hr / 3 hr+), passengers (1–4), mood (Hype, Chill, Romantic, Hungry, Explore, Surprise me). |
|---|---|
| R-02 | Shared rides: compact join codes and a QR flow so everyone connects to the same destination, mood and recommendations. |
| R-03 | Saved VYBEs so signed-in users can save and restore a ride setup. |
| R-04 | Voice that keeps the ride context across turns, with a typed fallback everywhere. |
| R-05 | Provider secrets server-side only; shared-ride membership through authenticated calls. |
| R-06 | Recommendations grounded in real provider results, never invented venues. |
4Solution architecture
A Vite + vanilla JavaScript front end carries the locked Variation 5 design. Vercel Functions sit between the browser and every provider, and Supabase holds identity and ride state.
VYBE Voice: live path
- 01MicrophoneBrowser MediaRecorder captures the request
- 02/api/voice-sttElevenLabs Scribe transcription (Web Speech API fallback)
- 03/api/voice-liveTranscript + ride context + recent turns
- 04Product actionFood, music, stops, mood, group activity
- 05/api/voice-ttsElevenLabs speaks the response
Ride generation: credential-gated
- 01Origin + destination
- 02Google Places (New)Resolve the destination
- 03Google RoutesCompute route and duration
- 04Model rankingAI Gateway or OpenAI
- 05SupabaseStore recommendations + saved VYBEs
5Demo / POC
Set destination, trip length, crew and mood once, then talk. The same context stays with the conversation.
6Technologies
- Vite
- JavaScript
- Vercel Functions
- Supabase
- ElevenLabs Scribe
- ElevenLabs TTS
- Web Speech API
- Google Places / Routes (gated)
- AI Gateway / OpenAI (gated)
7Integration points
| From | To | Detail |
|---|---|---|
| Browser | /api/voice-stt → ElevenLabs ScribeBase64 audio in, transcript out | Base64 audio in, transcript out |
| Browser | /api/voice-liveMessage, last turns, ride context | Message, last turns, ride context |
| /api/voice-tts | ElevenLabsSpeech for the response | Speech for the response |
| /api/rides/join | SupabaseAuthenticated shared-ride membership | Authenticated shared-ride membership |
| /api/health | All providersReports which services are configured | Reports which services are configured |
8Tradeoffs
| Decision | Instead of | Why |
|---|---|---|
| Grounded recommendations only | Instead of: Model-invented venues | A wrong restaurant in a moving car costs trust. Generation stays off in production until real Places/Routes data backs it. |
| Server-side functions for every provider | Instead of: Client SDKs | Keys never reach the browser, and a health endpoint can report exactly what is connected. |
| Scribe with a browser speech fallback | Instead of: One transcription path | Higher accuracy where recording works; the demo still answers where it doesn't. |
| Vanilla JS for the launch surface | Instead of: A heavier framework | Full control of the locked Variation 5 visuals and a fast load; the cost is more hand-built state. |
9Implementation & handoff
- Release gates and mobile QA are written down in the repository, so the next build ships against the same checks.
- A health endpoint turns 'is it working?' into a one-line answer for anyone supporting the product.
- Mobile requirements (Expo / React Native, Spotify, VYBE+ subscriptions) are scoped as next phases, not presented as shipped.
10What this demonstrates
- 1.Takes a fuzzy product idea through discovery to a requirements model a team can build against.
- 2.Designs and ships real API integrations (speech in, reasoning, speech out) with keys kept server-side.
- 3.Separates what is live from what is architected, and says so in the product itself.