Cushion

Inspiration

We kept seeing the same calendar pattern: a 9:00–9:30 meeting, a 9:30–10:00 meeting across campus, and a 10:00 call — with zero minutes between them. Google Calendar is excellent at recording time, but it does not understand the cost of switching contexts. People patch the problem manually by creating fake “buffer” events, declining meetings, or just showing up late.

That felt especially sharp for hybrid workers, students, caregivers, and anyone whose day includes travel between locations or recovery after intense calls. The missing feature was not another task manager. It was a small layer of realism: Cushion

What it does

Cushion adds smart buffer suggestions before and after Google Calendar events. When an event looks like it needs prep, travel, or recovery time, Cushion shows a small chip inside Google Calendar: “10 min prep,” “15 min travel,” or “5 min recovery.” Users can accept, edit, or dismiss each suggestion.

Accepted buffers are written to a dedicated Cushion calendar rather than modifying the original event. That keeps the feature non-destructive and easy to turn off. If a suggested buffer creates a conflict, Cushion flags it and suggests a more realistic time for flexible events.

The goal is simple: less double-booking, fewer fake events, and calendars that reflect how long things actually take.

How we built it

We built Cushion as a Chrome extension plus a small backend demo.

Chrome Extension Manifest V3 + React + TypeScript overlays Cushion controls on Google Calendar.

Google Calendar API + OAuth 2.0 reads events and writes accepted buffers to a separate “Cushion” calendar.

Gemini 1.5 Flash classifies event type and estimates prep/recovery buffers from title, duration, attendees, and location. We also built a rule-based fallback so the prototype still works if the model is unavailable.

Google Maps Distance Matrix API estimates travel time when an event has a location.

Node/Express backend handles OAuth token exchange and AI/Maps calls.

Vercel hosts the demo backend; GitHub hosts the source and README.

The buffer logic is intentionally simple and explainable. For example, we clamp a prep estimate between a minimum and maximum.

Challenges we ran into

The biggest challenge was that we did not have access to Google Calendar’s code. We had to build an overlay that feels native while surviving Calendar’s dynamic DOM. Selectors change, views re-render constantly, and the same event can appear in different layouts. We handled this by scoping our injection carefully and keeping the UI lightweight.

OAuth inside a Chrome extension was also fiddly: token exchange, redirect handling, CORS, and secure token storage all needed care. On the calendar side, recurring events, all-day events, time zones, and daylight-saving transitions made buffer placement more complex than it first appeared. We restricted the prototype to common cases and documented the edge cases.

AI reliability was another challenge. We did not want the model to silently invent buffers or overbook someone’s day. We used Gemini as a classifier and estimator, then applied deterministic constraints, confidence thresholds, and a rule-based fallback.

Accomplishments that we're proud of

We are proud that Cushion works end to end as a prototype: it reads Google Calendar events, suggests buffers, lets users accept or dismiss them, and writes accepted buffers to a dedicated calendar. The overlay feels close enough to Google Calendar that testers understood it immediately.

We are also proud of the non-destructive design. Cushion does not rewrite original events in v1. It adds a separate layer, which is safer for users and much easier for a company like Google to roll out gradually.

What we learned

We learned that calendar buffering is not just a time-math problem. It is a product and trust problem. Buffers are social: a 10-minute prep block may be fine for one person and unacceptable for another. Users need control, easy undo, and clear explanations.

We also learned to treat AI as a suggestion engine, not an authority. The best version of Cushion is explainable: “We suggested 15 minutes because this event is in another building,” not just “the model said so.” Finally, building on top of an existing app forced us to respect its patterns, privacy expectations, and failure modes.

What's next for Cushion

Next, we would turn Cushion into a Google Workspace Calendar add-on with per-calendar settings, org-wide admin defaults for travel/prep/recovery, and learning from accept/dismiss behavior. We would add mobile support, better recurring-event handling, and a privacy-first mode that keeps all estimation on-device. The long-term goal is not to fill calendars with more blocks — it is to make calendars honest about the time real work and real life require.

Built With

• css
• github
• html
• javascript
• node.js
• react
• restapi
• typescript
• vercel