DayBuddy — a daily companion I built for my friend Yashu

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

DayBuddy is a daily companion I built for my friend Yashu. Her routine kept slipping — sleeping past her alarm, skipping meals without noticing, losing track of what she meant to get done, and nobody actually checking in on how her day went.

DayBuddy wakes her up by name and reads out a short plan built around her real wake time, food and exercise preferences, and whatever is on her list that day — out loud, in plain English or Hinglish, whichever she's comfortable in. She can talk to it instead of typing: add a task, do her evening check-in, or ask "why was I tired this week?" by voice. Each night's check-in quietly shapes tomorrow's plan — a missed workout becomes a lighter start, a skipped meal gets a gentle nudge, never a guilt trip.

It's built so a bad network day never breaks her morning: no AI reachable, no database reachable, no voice service reachable — the app still answers with sensible defaults, every time.

Demo

Live app: https://daybuddy-yashu.onrender.com
API: https://daybuddy-yashu-api.onrender.com

(Both run on Render's free tier, so the very first request after a quiet period can take 30–50s to wake up — give it a moment.)

Code

https://github.com/Gautam5514/DayBuddy_hack

How I Built It

• Frontend — Next.js 16 (App Router), React 19, Tailwind CSS v4, shipped as a static export.
• Backend — Node.js, Express 5, with Zod validating every request and every model response.
• Open-source AI — Gemma 4 (Google's open-weight model), called through the free tier of the Gemini API. It writes the daily plan (greeting, schedule, meal and exercise suggestions, one specific tip) and answers questions about Yashu's own saved check-ins — only from what she's actually written down, never a guess. If Gemma is slow, unreachable, or returns something unusable, a deterministic rule-based planner answers instead, so the app never visibly breaks.
• Voice — ElevenLabs — Scribe turns her spoken tasks, check-in notes and questions into text (it understands Hinglish with no extra setup), and the text-to-speech voice reads the daily plan, answers, and a brand-new daily wake-up alarm out loud. The alarm rings once a day at her saved wake time while the app is open, speaking her greeting and that day's pending tasks — with a browser-voice and a plain tone as fallbacks if the voice service is ever unreachable, so she's never met with silence.
• Database — MongoDB Atlas, with an in-memory store as an automatic fallback and a background retry loop, so a flaky connection never takes the whole app down.
• Observability — Sentry Agent Tracing, tracing every planning and "ask" call using the gen_ai.* semantic conventions — one span per agent run, one child span per model call, with latency and token usage. Nothing else: no prompts or answers are ever recorded, because they're someone's private check-ins.
• Deployment — Render, a free Node web service for the API and a free static site for the frontend, defined as one render.yaml Blueprint.
• GitHub Copilot, configured with a .github/copilot-instructions.md file so Copilot's coding agent always has the real project context — the stack, the "never break on a failed service" rule, and the "no implementation jargon in the UI" rule — plus GitHub Actions (.github/workflows/ci.yml) that lints and tests the backend and lints and builds the frontend on every push.

Why Does Open Innovation Matter?

Because Gemma is open-weight and free to call through the Gemini API's free tier, I could build this exactly the way a friend building for a friend actually would: no budget, no enterprise contract, no vendor lock-in, nothing stopping Yashu from running her own copy later if she ever wants to.

Being able to see the full shape of a prompt and its response, instead of a black box, is what let me build a rule-based fallback planner that mirrors the AI one closely enough that Yashu — or a judge — usually can't tell which one answered. That same visibility is what made the Sentry Agent Tracing genuinely useful here: it traces real call structure and real token counts, not a guess at what a closed API might be doing behind the scenes. Openness is the reason the whole app can promise "it never breaks" instead of just hoping it won't.

Prize Categories

• Best Use of Gemma
• Best Use of ElevenLabs
• Best Use of MongoDB Atlas
• Best Use of Sentry Agent Tracing
• Best Use of Render
• Best Use of GitHub Copilot

Thanks for reading — and happy Hacktoberfest!