SayAhh

Inspiration

As children of immigrants, we have often helped our parents translate important information, wishing we could explain it better and offer more support. This has been especially challenging during doctor visits, where we are trying to translate medical concepts that we may not fully understand ourselves. We built SayAhh to help close that communication gap. We wanted patients to understand the conversation, feel comfortable asking questions, and leave with a clearer understanding of what was discussed. We also saw an application in clinical trials, where participants need to understand unfamiliar terms, uncertainty, and their choices.

What it does

SayAhh helps patients and healthcare providers communicate across languages. It translates their messages and simplifies complex medical wording into the patient’s preferred language, including plain English. Users can type or use supported browser speech features. Before an explanation or translation is shared, a reviewer can compare it with the original text, inspect a reverse translation, and check automated warnings. These tools support review but do not guarantee accuracy.

SayAhh also saves shared conversations locally, creates reviewable after-visit action plans grounded in the clinician’s instructions, and lets patients manually record health measurements and view trends. Optional patient preferences help make explanations more familiar and understandable. For our clinical-trial demonstration, we use a fictional study to show how a participant can read an explanation, ask a question connected to the source, and receive a translated answer from a human coordinator.

How we built it

We built SayAhh with Next.js, React, and TypeScript, using Tailwind CSS for styling and Zod to validate requests and responses. Google’s Gemini API powers the live explanations, translations, and action-plan extraction, with the API key kept on the server.

For translation and explanation, we use a second model call to render the generated text back into the original language without seeing the source. This gives reviewers another way to compare meaning, although the same model can repeat an error.

We connected the document guide, conversation, patient profile, and action-plan tools through shared application state. Browser storage preserves shared conversations and optionally saves profiles, plans, and manually entered measurements.

We used Gemini for early planning and Codex to assist with implementation, testing, debugging, documentation, and deployment.

Challenges we ran into

One of our biggest challenges was simplifying medical language without changing its meaning. A small difference in a number, a negation, or a statement of uncertainty can change what someone understands. We added source references, quantity checks, review warnings, and explicit approval before sharing. Another challenge was keeping information connected across the application. Changing a language, source document, or patient context must not leave an outdated translation or approval active. We also worked through browser-storage behavior, speech limitations, and model failures so that users could retain their input and understand what happened.

Accomplishments that we're proud of

We are proud of turning a personal experience into a working prototype that supports both sides of a conversation. Patients can ask questions in their own language, while healthcare providers remain responsible for supplying the answers.

We connected source-linked document explanations, bilingual conversations, local visit history, and reviewed action plans. The prototype supports live generation in 16 languages and prepared examples in six.

Our submission release passed 62 unit tests, 39 browser tests, TypeScript checks, and a production build. We also verified setup from a clean checkout and recorded a demonstration using actual Gemini responses. These are engineering checks, not clinical or language validation.

What we learned

We learned that translation alone is not enough. People also need context, understandable explanations, and an opportunity to ask questions.

We learned that fluent AI output can still contain mistakes. Keeping the original wording visible and making review part of the workflow became central to our design. We also learned how much reliable software depends on handling less predictable situations, such as changing settings mid-request, unavailable microphones, and interrupted model calls.

What's next for SayAhh

We want to bring SayAhh to mobile with a simple, accessible interface and dedicated experiences for patients and healthcare providers. Patients would have a personalized space to review visits, understand care instructions, and track their health, while providers would have tools to review explanations and support clearer communication.

We also hope to explore integrations with Apple Health, fitness apps, MyFitnessPal, and MyChart. With patient permission, these connections could bring relevant activity, nutrition, and medical information together. Optional tracking of habits such as smoking could help patients share a fuller picture of their daily lives with their care team.

Our goal is to support better-informed conversations and decisions between patients and providers. These integrations would require appropriate permissions, privacy protections, and clinical review before use with real patient data.