NaviDate

Home page
Talk with Navi!
Date selection
Date viewer
iMessage functionality

Inspiration

Ithaca is small, but campus still gets isolating. People disappear into work. You finally get a few free hours, then you spend them texting about where to go. Someone's across campus. A place closes at 8. By the time you agree, the evening is smaller than it was.

NaviDate is for those nights. You say when you're free and what two people can spend. It gives you a plan with real stops and the walk between them. You send the link and go.

Other schools feel like this too. Busy people, a short night, the decent spots a walk from the dorms. Once Ithaca feels solid, we want to try it somewhere else.

What it does

You put in where you're starting, when you're free, how long you have, what you want to spend for two, and the vibe. NaviDate comes back with a few options. Timed stops, the walk between them, a rough cost, and the weather for that window.

Tap a stop and it shows on the map. Swap one out and the rest of the schedule updates. Save, and you get a link. The other person can open it and look. Editing stays in the browser that made the plan.

You can skip the form. Talk to Navi and she asks for the details, then repeats them back before anything gets planned. Or text it to yourself and change the plan from Messages.

The stops are real places from Google. If we don't know the hours, the plan says so. Prices are estimates for two. Check before you count on the bill.

How we built it

It's one Next.js app, in TypeScript. React and Tailwind on the site.

A plan starts with a Google Places search near your start and around downtown Ithaca. Gemini picks an order from those places and writes the short descriptions. Our code then checks the hours, the budget, the time you actually have, the weather from Open-Meteo, and the walk from Google Routes. If a plan fails, it's gone. If none of them survive, Gemini gets one more try, and we tell it why the first round failed.

Navi's voice is Grok, through xAI. She can talk and collect what you want. She confirms it before it goes anywhere. Picking the places is still Gemini, plus those checks. The browser only gets a short-lived token, so the API key stays on the server.

Texting is Photon, in a worker that stays running next to the site. They share a database, so a link from iMessage opens the same plan. You hit "send to myself," Messages opens with a pair code, you send it, and then you can ask about the date or change it from that thread.

Challenges we ran into

Places, Gemini, Routes, Grok, and Photon all responded pretty fast. The slow part was getting them to agree on one date.

We had a website, a voice agent, and a text agent. Left alone, each of them would plan the evening itself, and we'd have three demos under one name. Photon was the clearest case. It will not sit inside a normal web request. It needs a process that stays up, reads texts, and remembers the conversation. So the worker runs beside the Next app, and they share storage. If they don't, the link in a text opens nothing. Pairing took a while too. The site does not text you. You send a code from your phone, and then that thread can see the plan.

Gemini was the other problem. It will write a nice evening without checking much. Hours, what two people spend, which way you walk: those came out wrong often enough that we stopped trusting them. It can only pick places from the search we just ran. The schedule checks live in our code. No walking route from Google, and that option is out. If Places or Gemini fails, you see the error and your form is still there. We did not want a failed request to quietly turn into a different plan.

Accomplishments that we're proud of

You can build a date on the site and change it later by text, and both go through the same checks. Hours, budget, weather, the walk. The update is a new link. Whoever already has the old link is still looking at the old plan.

Navi asks for the details and reads them back. After that, the plan comes from the same place as the form.

Missing hours stay missing. If Google never sent a walking route, the map does not invent one.

What we learned

Most of the weekend went into a boring question. What is each piece allowed to do? Voice, text, and the website all tried to plan the date. They're fine at taking what you want. Building the itinerary had to happen in one place, or the hour and route checks didn't apply to half the product.

The worker was the same kind of fight. Stuffing Photon into the web app looked simpler. It needs something that stays running. The site needs to save, share, and edit. Separate processes, one database, one planner. After that, a text and the form were the same app.

A list of Ithaca spots is easy. Getting from Arts Quad to dinner downtown, in the time you have, in that night's weather, is the useful part. We treated it like a detail for too long.

What's next for NaviDate

We built this for Ithaca because it's where we are. Other schools have the same nights. Everyone's busy, the good spots are a walk from the dorms, and planning eats the evening. Next we'd take it to another college town and see what breaks.

In Ithaca, the big gap is the bus! Walking campus to downtown isn’t always the move, and we didn’t have real TCAT times, so those plans just aren’t there yet.