Ganesh Chaudhary

What I built

1. Voice

   Speak a to-do, refine it by talking

   I integrated Gemini Live so a student can say a task out loud and adjust it in conversation, with no restart. The backend issues short-lived, single-use, model-locked tokens and the browser connects straight to Gemini, so the whole backend runs as one Vercel serverless function with no WebSocket proxy.

2. Dates

   Spoken times that land on the right day

   I built a timezone-aware converter from wall-clock time to UTC and threaded the student's real timezone through every date-resolution path, so a phrase like “tomorrow at 5” resolves correctly. Students can also correct the resolved due date by hand.

3. Google

   Calendar, Tasks and Classroom sync

   I worked on syncing to all three, including writing task completion back to the real Calendar event. I fixed sync states that got stuck silently, and made the app treat an unreadable Google connection as something to recover from instead of a crash.

4. Check-ins

   End-of-day check-in and notifications

   I designed and built the whole flow.

   • Finish-time entry, snooze, daily confirmation and catch-up
   • Reminder times saved per user in the database, not in an in-memory global
   • Web Push and an in-app notification bell
   • A scheduled job (GitHub Actions and a Supabase cron migration) that dispatches due check-ins

5. PWA

   Installable on iOS and Android

   Cross-platform work so the app behaves like a real installed app.

   • iOS and standalone-mode detection, install metadata and an install option in the app
   • Fixes for service worker and manifest caching problems
   • Microphone permission fixed in the installed iPhone app, plus detection of a mic that connects but never captures audio
   • A real-browser end-to-end suite for iOS and Android push

6. Accessibility

   An app-wide audit, fixed to WCAG AA

   I ran a UX audit across the app and resolved the Very Major and Major findings, plus the Minor ones. The fixes covered WCAG AA colour contrast, aria-live and role=alert on async status text, ARIA landmarks, touch-target sizes, and consistent focus and disabled states.

7. Reliability

   Security and stability

   The Live token endpoint requires authentication, voice sessions are guarded against re-entry, and Supabase calls are wrapped in error handling. I also fixed flaky tests, including a time-dependent scheduling test and an extraction test that made real network calls.

8. Delivery

   CI, deploys and migrations

   I set up the CI workflow, sped up deploys by installing frontend and backend dependencies in parallel, and fixed production build failures. Schema changes go through versioned Supabase migrations.

By the numbers

non-merge commits are mine

160 of 286

pull requests merged

~190

database migrations

19

test files

77

CI workflows

2

Jira tickets assigned to me are done

88 of 89

Taken from the project's git history and Jira board on 17 September 2026, covering 17 July to 17 September. Both are private, so there is no public link to check them against.

How I work with the team

1. 01

   Specs become software

   I work from plain-language product specs written by the product owner, often with screenshots, and treat each epic as the source of truth for intent. I break epics into stories and subtasks, and I am the reporter on 128 of the project's 181 tickets.

2. 02

   Ask before building

   On the weekly summary feature I posted my starting plan and asked for a decision first. I proposed a read-only link a student can share instead of sending email in version one, and generating the summary on demand instead of sending it every week. I explained that this keeps the first version simple, and left the choice to the product owner. When a ticket leaves out a priority or an estimate, I ask instead of guessing.

3. 03

   Two audiences, two registers

   Technical status goes to the engineers, and a plain-language note closes the ticket for the product owner, for example: “Notifications are now more reliable if a send fails, and we catch a case where a student’s phone thinks it’s set up but it isn’t.” Pull requests read the same way: what changed for the student, not which files.

4. 04

   Own the gaps

   On a push-reliability ticket I wrote that my first comment only covered half the spec, then reported the rest: a status endpoint, a banner in Preferences, a one-tap fix and tests. I also flagged a gap my own cleanup of dead subscriptions could cause, and fixed it in the same ticket.

5. 05

   Small, reviewable changes

   Every change goes through a pull request with a named reviewer, on a branch off main. I keep one pull request to one coherent change, describe it as context, what it solves and how, and add a small diagram when the change has a shape worth drawing.