Düky | Devpost

Inspiration

While working on projects I would notice myself often coding in isolation and have trouble describing concepts that I was confident I knew about, or even have low-energy days where I didn't know what to tackle next. A tale as old as time for every developer, so common there was even a method coined, "Rubber Duck Method," which helps developers debug and forces clarity when articulating. Often the brain works in the background, so we also encourage users to take breaks when there is a meaningful pause in our busy day-to-day lives.

What it does

Düki is a mood based task companion built around the idea that you should just be able to talk to it. You open the app, ramble about what's on your plate or how your day is going, and Düki turns that into real tasks, broken down into subtasks, each with a rough time estimate attached. It pulls in your Google Calendar so it actually knows when you're free, and it asks how you're feeling once a day, so a low energy morning gets you short, easy wins instead of the hardest thing on your list.

When you're ready to focus, Duck Mode locks your screen and goes quiet, the same way a real rubber duck would, so you can just work. And because staying productive doesn't mean staying at your desk all day, Düki also knows when to nudge you toward a break, whether that's a chore you've been putting off or a local event nearby, food, music, a market, something to get you off the screen for a bit. At the end of the day it shows you how your estimates held up against reality, so the next ramble gets a little sharper.

The core loop is simple: talk, plan, act, and debrief.

How we built it

The frontend is built with Next.js and TypeScript, while FastAPI powers an asynchronous Python backend. Supabase provides PostgreSQL, authentication, and row-level security. Google OAuth uses PKCE and offline consent so encrypted Calendar refresh credentials can be stored safely. Voice is transcribed through Groq-hosted Whisper, then passed through a provider-neutral structured extraction layer that can use Groq or OpenAI without changing the surrounding business logic.

Modularity was on the top of my mind, so when I started using Codex I would attach a rule for modular ports-and-adapters architecture. This meant that a big investment early on would result in changes that touched less files, and therefore made the codebase more focused and intentional, as opposed to dumping grounds for ideas.

Challenges we ran into

An early challenge was figuring out how to design the authentication and Google calendar consent so refresh tokens would remain available without users having to constantly sign in again. We got through this by breaking down the task into smaller manageable and testable chunks:

Creating the provider-neutral OAuth authorization flow
Validating Supabase sessions
Saving encrypted refresh credentials
Exchanging PKCE codes Bumps in the road included creating the right callback endpoints and orchestrating the flow with the app, Supabase, and Google Cloud before the frontend was implemented.

Another challenge was deciding when a spoken statement represented a new task, an update to an existing task, or simply conversation. A debrief such as “I finished the frontend and it took 75 minutes” should not create a duplicate task, but completed unplanned work should still be recognized. We addressed this with open-task context, structured extraction, deduplication, resolution suggestions, and a final user-confirmation step.

Free-tier AI services introduced rate limits and confusing errors. We added bounded retries, explicit provider errors, and persisted failed session states so one unavailable integration would not crash the application or erase the user’s transcript.

Additionally, I didn't want to over-engineer the user's schedule so we only selected to schedule on working hours. Rambling shouldn't feel like a task either so making that inviting and allowing users to open up about their day was a challenge actively worked on by testing the product.

Accomplishments that we're proud of

Built an end-to-end Google OAuth flow with PKCE, offline consent, encrypted refresh-token storage, and Supabase session validation.
Turned unstructured voice rambles into estimated tasks using a provider-neutral transcription and extraction pipeline.
Combined mood, working hours, and Google Calendar availability to produce realistic daily plans.
Reconciled ad hoc debriefs with existing tasks while recognizing unplanned accomplishments and always running final plans through the user.
Captured actual duration and perceived difficulty against original estimates, creating the foundation for meaningful personal insights.
Built the project incrementally through small, human-reviewed commits with Codex assisting implementation, verification, and architectural consistency.

What we learned

Learned how to create an agent ruleset and roadmap from a generated PRD to execute my plan. As well as control budgets, at first I didn't realize that Codex was using the very expensive quick response, and for prototyping I offloaded the extraction and interpretation tasks to Groq's free tier.

Creating the voice to text pipeline was a new experience, I've only sent text through APIs so sending data as binary representations whose transcript is saved to a database was something I had a lot questions on.

Creating a foundation makes development easier, testing often makes it accurate even though I spent more time than I would've liked doing so.