Inspiration
I’ve seen it a few times: someone leaves a role or finishes a project, and the handover is a mix of last-minute docs, a long call, and a “just ping me if anything’s unclear.” A lot of what actually matters, who to talk to, how things really work, where the traps are, never makes it onto the page. The successor is left to reverse‑engineer everything.
I wanted to try something different: what if the handover itself was a guided conversation? Not just a form to fill, but a live session where the outgoing person talks (and maybe shares their screen), and the tool helps them cover the right topics and then turns that into a real handover pack the next person can use. That’s the idea this project grew from—making handovers feel more like a good conversation and less like paperwork.
What I learned & how I built it
On the technical side, I got deep into a full‑stack, real‑time setup: a React + Vite front end that streams audio and talks to a FastAPI backend that runs sessions, transcript analysis, and storage. I had to think in two time scales at once: streaming(so the user sees words as they speak) and analysis (so we only ask the AI to think when there’s a full thought, not on every half‑sentence). That led me to voice activity detection and debouncing: simple ideas, but they made the difference between “responsive” and “laggy and expensive.”
On the human side, I learned how much handovers depend on structure. Having clear templates (Role, Project, Process, System) and sections (e.g. “Risks & Mitigations”, “Tools and Systems”) didn’t just organize the doc, it gave the AI (and the person leaving) a map of what “complete” looks like. I also had to care about production details I used to skip: CORS, env vars, and where the API key lives. When the app is public, those details are the difference between “it works on my machine” and “it works for everyone.”
The bumps in the road
Real time vs. good enough timing. At first I was tempted to analyze every little fragment of speech. The result was noisy, expensive, and sometimes incoherent. The shift was to accept that we don’t need to understand very word the moment it’s said—We need to understand turns. So the tool now wait for a pause (and a minimum amount of speech), then send a chunk. That single change made the system feel smarter and cost a lot less.
One analysis, not two. Originally I made two Gemini calls per chunk: one for follow‑up questions, one for entities (tools, systems, people). I merged that into a single call that returns both. Fewer round trips, lower cost, same (or better) quality. It was a good reminder that the first design doesn’t have to be the final one.
When the primary model is overloaded. Sometimes the main model (e.g. Gemini 3) would return 503. Rather than showing a generic error, I detect that and fall back to another model (e.g. Gemini 2.5). The user might not even notice; they just keep going.
Stale state in callbacks. The analysis runs inside the Gemini Live onmessage callback. At one point the callback was using an old React sessionId, so I was posting analysis to the wrong session. Fix: keep the current session id in a ref and read from that inside the callback. Small detail, big impact.
Keeping the AI honest. Early on, the model would sometimes fill sections with plausible‑sounding text that wasn’t in the transcript. That’s dangerous for a handover, the successor might act on something that was never said. So we tightened the prompt (“only use explicitly stated information”) and added a sanity check on transcript length vs. generated content. The goal is: the document should be a reflection of the conversation, not a creative rewrite.
Where it stands now
What started as “what if I could make handovers less painful?” turned into a full pipeline: templates, live recording with three modes (add on edits/sessions available), real‑time transcription, turn‑based analysis, AI suggested edits and rewrite , AI chatbot to help navigate the documents within the platform and a strict synthesis step into a structured handover pack. There were a lot of small decisions, when to analyze, how to debounce, how to validate, that together made the tool both useful and trustworthy enough to share publicly.
If you’re reading this on the project page, thanks for taking a look. I hope the story behind it is as useful as the tool itself.
Built With
- fastapi
- firebase
- gemini
- github
- node.js
- postgresql
- pydantic
- python
- railway
- react
- typescript
- uvicorn
- vercel
- vite
Log in or sign up for Devpost to join the conversation.