Delta-T

• 

  The delta-t dashboard

Inspiration

Planning tools often show what’s on the calendar without showing whether there’s realistically enough time to get everything done. We wanted to go beyond simply planning for tomorrow and ask a more useful question: “What if we could solve tomorrow's problems before they happen?"

What it does

Delta-T turns a user’s tasks and plans into a day-plan review. The user can connect Google Calendar to the system, and the events of the next day are automatically imported into the system. The tasks are entered in a to-do list form, where every task is given a name, deadline, estimated length, completion percentage, and whether the task should be completed in one sitting. The user can also adjust preferred transport, work hours, simulations per scenario, and where they start their day in settings to make suggestions more personalized. Delta-T combines that information with available time slots, route, and weather data, then simulates the plan to estimate risks such as missing a task deadline or arriving late to an event. It proposes possible task-schedule adjustments and compares predicted risks before and after those changes. The results highlight high-risk tasks, explain relevant constraints where the available data supports it, and flag cases where a deadline or schedule may be infeasible. Delta-T can also suggest that a calendar event might be movable when its title or description suggests flexibility, e.g. a call with a friend rather than a lecture. These are only suggestions: Delta-T does not edit Google Calendar, and a suggested event move is not included in the simulation as a verified improvement. Similarly, suggested task start times serve as scheduling hints rather than guaranteed, reserved time blocks.

How we built it

The frontend is built with TypeScript, React, and Next.js. The backend uses Python and FastAPI. We use Google Gemini to extract and review plans; Google Calendar to read commitments; Open-Meteo for weather; and optionally Google Maps Routes API for route estimates. NumPy supports the Monte Carlo simulation. The workflow separates plan intake, risk prediction, repair suggestions, and comparison. The frontend collects the user’s tasks and preferences, then sends them to the backend for a plan review. On the backend, an orchestrator coordinates the review. All the details are packaged into a shared context so the planning steps use consistent information about the day. The review then runs in stages. The Monte Carlo simulator estimates the risk of missing task deadlines or arriving late to events. It accounts for modeled work hours, calendar commitments, travel estimates, and weather effects. After a candidate task schedule is proposed, the backend simulates it again and compares its risk results with the original plan. The final review reports both the measured comparison and the agent’s explanation.

Challenges we ran into

1. Finding the right idea Ideation took longer than expected, so we had a slow start. Once we aligned around the problem we wanted to solve, momentum picked up quickly.

2. Debugging the black box Gemini calls were taking 1.5–2.5 minutes, while the dashboard simply displayed “Sending…”. We added step-by-step logs and timing measurements to pinpoint delays. This also exposed silent fallbacks, such as travel estimates defaulting when the Google Maps API key was missing.

3. Keeping everyone on the same page Different assumptions about time formats, event and task structures, and the simulation window caused integration bugs, some appearing only with real calendar data. We had to standardize our data models and time conventions, and fix issues such as the simulator ignoring the intended starting location.

Accomplishments that we're proud of

1. A working loop from a button click to an explained plan: the app reads your Google Calendar, forecasts the weather, looks up routes, and shows how likely you are to be late or miss a deadline.

2. A simulation that checks the AI. Gemini proposes a better ordering of your tasks, and the same Monte Carlo simulation re-scores it. The "improved / worse" verdict is plain arithmetic, so the model never grades its own work.

3. Real data and real guardrails: calendar access is read-only, the repair step can't change fixed events or deadlines, and calendar-move suggestions are labelled advisory and never applied. A tested backend with a readable log of every step of the workflow.

What we learned

1. Treat LLM output as untrusted input: validate it, retry on failure, and let deterministic code produce every number.

2. Make a system observable early. Silent fallbacks hide problems for a long time.

3. Agree on data contracts and time conventions before building, because the fixes get very tedious and time consuming across four people's code.

4. Be honest about what a simulation can show. Our repair step can currently only reorder tasks, so it can't reduce lateness to meetings, and unseeded randomness means small before/after differences can be noise.

What's next for Delta-T

• Improve per-task diagnostics so risk explanations can be more specific and evidence-based.
• Make flexibility recommendations clearer by explaining why an event might be movable and labeling suggested times as unverified.
• Let users mark commitments as flexible or fixed, rather than relying on the agent to infer flexibility from event titles.
• Support calendar changes with user approval, so the agent can propose and, if approved, make schedule adjustments.
• Explore email integration to identify relevant events missing from the calendar and draft rescheduling emails for the user to review and send.

Built With

• fastapi
• next.js
• python
• react
• sqlite
• typescript