Here's what you'll see after Sunday has processed your email inbox:

• React frontend with Framer Motion animations and UI design
• Node.js + Express backend with a cron job running to automatically process incoming emails
• OpenAI for generating email draft responses and powering the chat assistant via a RAG (Retrieval-Augmented Generation) pipeline
• MongoDB Atlas for data storage, with Vector Search (1536-dimension embeddings) enabling semantic retrieval of email history
• Google OAuth 2.0 + Gmail API for authentication and all email read/write operations
• Twilio for SMS notifications

I built Sunday Mail as a cheaper alternative to a Y Combinator-backed company doing something similar, but charging $100/month. The core idea was simple: let users write automation rules in plain English ("if someone asks about invoices, draft a reply and text me"), and have the app handle the rest silently in the background. I ended up implementing a full RAG pipeline so it could reference real email history rather than hallucinate context. Storing embeddings directly in MongoDB Atlas kept the architecture clean without needing a separate vector database. The cron-based polling approach trades some latency for simplicity, which was the right call at this stage. There's a natural next step toward a recommendation or triage system using the embeddings already being collected, and adding more email providers beyond Gmail would open it up significantly. Overall, this was a great project for me to learn more about building RAG pipelines from scratch!

Implemetning this integration involved:

• Turned Terraform plan output into APIC-style JSON payloads so infrastructure defined in Terraform could be expressed in the same object model the controller expects, without hand-writing REST bodies
• Mapped Terraform resource attributes and lifecycle (including deletes) to ACI classes, DNs, and parent/child relationships so planned state stayed consistent with how the fabric is modeled
• Centralized per-resource conversion behind a registry and reused the provider’s own create/delete payload logic so generated payloads stayed aligned with production behavior as resources evolved
• Hierarchical assembly — Built a merge step that combined flat per-object fragments into a single tree under the fabric root (uni), with metadata-driven class resolution along DN paths for correct nesting
• End-to-end validation — Added an optional path to push the generated payload to APIC and re-check Terraform plans so conversions could be verified against a live fabric, not only static JSON

Network programmability was a new frontier for me, so this project was a great learning experience. This project was interesting to work on because of the real-world application and potential for growth. What excited me the most was seeing the potential for this technology to essentially solve all network incidences that could arise from infrastructure configuration changes. As for the development process, I ended up gaining a much deeper understanding of the networking and infrastructure as code. It took a lot of time and learning, but I enjoyed the process!

• Next.js for building the front end
• Tailwind CSS for styling
• Vercel for deployment
• A couple of APIs & services:
  • Letterboxd RSS feed for recently watched movie data
  • Last.fm API for Spotify listening data
  • Deezer API for music artist images
  • Nodemailer for emailing recommendations

I was initially unsure about whether I should make this website strictly professional or a little more casual. Ultimately, I leaned into the latter because I wanted it to be like a snapshot of the person I am right now.

I built this website from scratch and I'm a bit of a perfectionist, so it ended up becoming a never-ending cycle of tweaks and refinements. I became very fixated on tiny design choices; as a result, I spent an embarrassing amount of time browsing fonts, adjusting hex codes, and trying out different hover animations. Still, it was fun and it felt very rewarding to create something that grows alongside my interests. I'll try to keep this website as up to date as possible.

The user would express the task that they are trying to accomplish; for example, maybe they want to practice Leetcode and get a job. The extension would then start observing their activity, making snarky comments verbally and nudging them to get back on track (hence the name). If they opened a problem and went straight to the solution, they would get called out. The extension "speaks" out loud in a tone and voice that's meant to mimic the narrator in The Stanley Parable.

• JavaScript for the core functionality and user activity monitoring
• React for the extension's pop-up and dashboard
• MongoDB for storing activity logs
• Flask for the back end
• GPT-4 (OpenAI) for generating responses
• Eleven Labs TTS for giving voice to the narrator

This product isn't perfect (most hackathon projects aren't), but it taught me a lot about how Chrome extensions work under the hood. I gained some pretty valuable full-stack experience, but unfortunately also learned firsthand about how frustrating Chrome extensions can be to debug, especially when I'm trying to trace different messages and errors between background scripts, popups, and content scripts. However, this made it extra satisfying when the project started coming together nicely. I enjoyed the process of building Nudge, especially in the unique environment of a hackathon, and found the premise to be really fun to design.