DayGo

• 

  Dashboard

• 

  Calendar

• 

  Mobile Layout

Inspiration

Everyone does the same mental math every morning: "it's a 20 min drive so I gotta leave by 8:40." We wanted an app that just does that for you instead of you eyeballing it. Google Maps tells you how to get somewhere. Nothing really tells you when you need to walk out the door.

What it does

DayGo works backwards from your day instead of forwards. Give it a destination, when you need to arrive, and how you're getting there (car, transit, walking, biking), and it spits out the exact time you need to leave, buffer included. Attach that to a calendar event and it keeps recalculating as stuff changes, like a delay you know about, live traffic, whatever.

It grew way past just that though. By the end we had:

• A full calendar with one-off and recurring events (daily/weekly/monthly, pick your weekdays, set an end date), plus you can edit or cancel just one occurrence without messing up the whole series
• A live Mapbox map showing where you are and the route to your next thing
• A weather-aware daily summary so you know if rain's gonna slow your commute down
• Browser notifications that ping you before an event, with a lead time you can set
• JSON import/export and an archive for past events

How we built it

Backend: Java 17 and Spring Boot, with a small REST API that handles the departure math and turns recurring event rules into actual calendar dates. It calls Mapbox for geocoding and routing, and falls back to rough per-mode estimates if a location won't resolve or the API call fails.

Frontend: Just plain HTML/CSS/JS with Mapbox GL JS for the map, no framework. That let us move fast and just keep iterating on the UI all weekend instead of fighting a build setup. Weather comes from Open-Meteo based on your location.

Challenges we ran into

The biggest challenge honestly wasn't the backend, it was figuring out the UX. Building out the departure-time math and calendar logic on the backend was pretty straightforward. The hard part was coming up with a frontend that actually made good use of it, what the app should look like, what features mattered, how it should feel to use. Once we landed on a design we liked for the web app, everything got easier: we could keep layering on UX improvements and new features one at a time until it felt like one cohesive, useful app instead of a pile of disconnected capabilities.

Recurring events were also way harder than we expected. Getting "every other Tuesday and Thursday until March" to expand into the right actual dates, and letting someone edit or delete just one occurrence without breaking the rest of the series, took a bunch of tries to get right.

Routing was its own headache too, real geocoding and directions APIs fail in weird ways (bad addresses, no route found, rate limits), so we had to build fallbacks for every travel mode instead of assuming the API always cooperates.

We also learned the hard way that hardcoding API keys straight into your repo is a bad idea the second it goes public. Had to go back and fix that properly, rotate the keys, and move everything into environment variables instead.

Accomplishments that we're proud of

Going from "one simple departure time calculator" to an app with recurring events, a live routed map, weather-aware summaries, and notifications, all in one weekend. Honestly feels like something we'd keep using ourselves, not just a demo we throw away after judging.

What we learned

This project taught us a lot about how a real web app actually works under the hood, not just in theory.

We learned that connecting a frontend to a backend means thinking in requests and responses instead of just function calls, and that you have to design for things arriving late or out of order, like the map not being loaded yet or weather data not being back yet, since none of that comes up when everything runs in one process.

Hitting CORS issues taught us that the browser treats your own backend as a stranger unless you explicitly tell it otherwise.

Debugging across the frontend/backend boundary also taught us to reach for browser dev tools and server logs together, since a bug could be hiding in either layer, or in the request between them.

And getting burned by a hardcoded API key taught us a lesson we won't forget: keep secrets out of the repo from day one, not as a cleanup step after the fact.

What's next for DayGo

Actual persistent storage instead of in-memory data, deeper calendar sync so DayGo can pull from a calendar you already use instead of just its own, and real routine scheduling, recurring whole days, not just recurring events, kind of like how Notion helps you plan out a day and not just a commute.

Built With

• css
• html
• java
• javascript
• spring