SpeakEasy

SpeakEasy used to listen in on new alerts in #speakeasy-demo

Inspiration

Distracted driving kills thousands of people every year, and checking Slack is part of that problem. It's not just a driving issue either; anyone with a visual impairment, limited mobility, or a hands-busy job faces the same barrier: a screen they can't safely look at while staying connected to work. We wanted Slack to work by voice instead of by screen.

How we built it

The backend is Python, Flask, and Slack Bolt, verifying signed Slack requests and listening for messages in channels where /speak-alerts on has been run. Each qualifying message runs through a keyword-based priority check, then gets sent to Groq (Llama 3.1) for a short spoken summary. A voice Q&A endpoint lets users ask what's happening in a channel and get an answer grounded in recent messages. The frontend is plain HTML, CSS, and JavaScript using the Web Speech API to actually speak summaries aloud, styled to look like a phone or watch companion app. We used ngrok during development and deployed the final backend to Render with gunicorn.

Challenges we faced

Most of the real work was debugging, not writing new features. An environment variable got read before it was actually loaded, which silently crashed the server on boot, only caught by actually running it, not by reading the code. Our priority detection flagged a message like "lunch was good today" as high priority just because it contained the word "today," which we only found by deliberately testing an ordinary message instead of just the happy path. We also switched LLM providers from Claude to Groq partway through to keep the project free to run, which meant re-verifying every prompt actually still worked well rather than assuming it would carry over.

What we learned

Code that looks correct and code that actually works are different things. The bugs that mattered most only surfaced by running the real server, simulating real signed Slack webhook deliveries, and watching the full pipeline execute end to end, not from reading the code. We also learned not to assume behavior carries over when something changes underneath you, like a model provider, you have to go re-check it.