> ## Documentation Index > Fetch the complete documentation index at: https://foundry.awaaz.de/llms.txt > Use this file to discover all available pages before exploring further. # The Backlog in Your Head > February 2026 — Build the thing you have been waiting to build **Date:** Friday, February 26, 2026\ **Time:** 4:30 PM – 9:30 PM\ **Format:** Individual *** ## You Already Know What to Build There's something you've wanted to fix for months. Maybe it's a dashboard that should exist. A workflow that wastes twenty minutes of your day. A tool you keep describing to colleagues as "someone should really build this." A rough idea you've sketched on paper or prototyped in your head during a long meeting. It never made it to a sprint. There was always something more urgent. The roadmap had other priorities. You told yourself you'd get to it eventually. This is eventually. *** ## The Challenge No assigned problem statement. No spec handed down. This is your product sense, your frustration, your vision — made real in three hours. Build something that makes Awaaz better. That's the only brief. You've spent years inside this product. You know where it creaks. You know what's missing. You know what would make your own life easier, or a consultant's day shorter, or a customer's experience smoother. Now is the time to prove it. *** ## Why This Format We want to see how you think, not just how you code. Anyone can execute a spec. The harder skill is identifying what's worth building in the first place. What problems do you notice that others walk past? What solutions are obvious to you but invisible to everyone else? This hackathon is a window into that. *** ## How It Works ### Phase 1: Problem Lock-in (First 30 Minutes) You must submit your problem statement within the first 30 minutes. Earlier is better — every minute spent deciding is a minute not spent building. Submit a short write-up covering: What problem are you solving? Be specific. "Improving call quality" is too vague. "Detecting when an agent repeats the same response three times in a row" is concrete. Why does this problem matter to you? Have you felt this pain personally? Seen others struggle with it? Noticed it silently costing us time or money? Why haven't you built this already? What's been stopping you — time, priority, resources? This is your chance to finally do it. What will you demo at the end? A working tool? A prototype? A visualization? Be clear about what "done" looks like. Submit the problem statement in general channel. Once you submit, you're locked in. No pivots. This forces conviction; pick something you genuinely believe in. *** ### Phase 2: Build (Remaining Time) After lock-in, you build. Use whatever tools you want: * Claude Code, Copilot, ChatGPT * Existing libraries, your old code, open source all fine This isn't a test of what you can do without help. It's a test of what you can ship with everything at your disposal. *** ### Phase 3: Demo At the end, you show what you built. No slides. Just your screen and your voice. Show us: 1. The problem (briefly) 2. The solution (this is the main event) 3. Why it matters (land the plane) If it doesn't run, it doesn't count. A working prototype that solves a small problem beats a broken attempt at something ambitious. *** ## Schedule | Time | Phase | | -------------- | ----------------------------------- | | 4:30 PM | Kickoff | | 4:30 – 5:00 PM | Problem statement submission window | | 5:00 PM | Hard deadline for problem lock-in | | 5:00 – 8:30 PM | Building | | 8:30 PM | Code freeze | | 8:30 – 9:00 PM | Demos | | 9:00 – 9:30 PM | Voting and wrap-up | *** ## Evaluation Criteria **25%** — Did you identify something real? Is this a problem worth solving? Does it show understanding of the product and its users? **35%** — Does it work? Is it usable? Did you actually build what you said you would? **25%** — If this were polished and deployed, would it matter? Would people use it? Would it save time, money, or frustration? **15%** — Can you explain why this matters? Is your demo coherent? Do you understand the problem deeply? *** ## What Makes a Good Problem Choice * Specific and scoped ("Detect repeated agent responses within a single call") * Comes from real experience ("I noticed this while reviewing calls last week") * Achievable in 3.5 hours ("I can build a working detector and basic UI") * Has clear value ("This would help QA catch stuck agents faster") * Vague ("Improve agent quality") * Never experienced firsthand ("I think customers might want this") * No clear finish line ("Make calls better somehow") *** ## Inspiration Corners You don't need these. If you already know what you're building, skip this section entirely. But if you're staring at a blank page, here are some areas where we know problems exist: * What do you debug repeatedly? * What logs do you wish existed? * What's missing from your local dev setup? * What would make code review faster? * What patterns indicate a call is going sideways? * How would you spot a bad agent config before it hits production? * What would help consultants review calls faster? * How do we know if a prompt change made things better or worse? * What should be on a dashboard that isn't? * What alerts would have prevented the last incident? * Where does latency hide? * What's the canary that tells us something is off? * What makes calls feel robotic? * Where do conversations break down most often? * What confuses customers that shouldn't? * What would make our agents sound more human? *** ## One Last Thing This isn't about proving you can code under pressure. We already know you can. This is about showing us what you see that others don't. The problem you've been carrying around. The solution that's been forming in the back of your mind. You've been waiting for time to build it. Here's your time. *** The winner receives a **USD \$20 one-time credit** towards a course or book of their choice.