The problem
Typed survey responses are thin, and everyone knows it. Faced with a free-text box, most people write the shortest thing that will dismiss it, which is why the qualitative section of a survey is usually the part nobody reads.
Speaking is different. People say more, they say it in their own words, and they will explain themselves out loud in ways they would never type. The reason surveys are not built that way is that voice is easy to collect and hard to do anything with afterwards.
The constraint
Fourteen days, with three vendors in the request path
The build window was two weeks, which decides the architecture before any design work starts: nothing gets built that can be bought, and the only original code is the part no vendor sells.
So voice generation and transcription go to ElevenLabs, analysis to OpenAI, and auth, storage and realtime to Supabase. What is left to build is the survey model, the conversation flow, and the analytics that make a pile of spoken answers readable.
The cost is that three external services now sit inside a live user interaction, each with its own latency and its own failure mode, and a respondent who is mid-sentence cannot be shown a spinner and asked to be patient.
What I built
- 01
Buy everything that is not the product
Supabase supplies auth, storage and realtime out of the box, which removes an entire week of backend work that would have produced nothing a user could see.
The judgement in a two-week build is almost entirely about what not to write.
- 02
Conversational, not just voice input
The survey responds rather than only listening. That turns the interaction from dictation into a conversation, and conversations are where follow-up happens, the reason spoken feedback goes deeper than typed feedback in the first place.
- 03
Transcribe in real time so the respondent sees they were heard
Speaking into an interface that shows no sign of receiving you is deeply uncomfortable, and people stop early. Live transcription is partly a feature and mostly reassurance.
- 04
Vite, because there is nothing to server-render
The application lives behind auth, so server rendering buys nothing a user would notice, while the faster development loop compounds every hour across a fortnight.
- 05
Analysis is the product, not the recording
Voice responses are worthless if reading them takes longer than reading text would have. The dashboard exists to read across responses rather than through them, which is the actual reason to run the model over the transcripts.