Mirror
AI communication coaching for founders who think in their second language
Product
AI communication coaching
Stage
Zero to one
Role
Solo founder · Design & development
Product Link
AI already remembers what was said, not how it landed
Founders replay their meetings at night
A founder can leave a meeting knowing exactly what was discussed and still spend the evening wondering why it felt wrong. Was the ask unclear? Did they spend too long explaining? Did the other person understand what they wanted?
There are already good tools for remembering meetings, including Granola, Otter and Fireflies. Tools such as Yoodli and Poised give people feedback on how they speak. I became interested in a narrower problem — what happens when someone is speaking fluent English, but the way they phrase an important point makes it harder for the other person to understand their intent?
I started with founders from Eastern Europe having important meetings in English with Western counterparts. A polite, softened request can be perfectly natural to the person making it. In a particular meeting, though, it may leave the other person unsure whether anything is being asked of them. Mirror should be able to point that out without treating politeness, an accent or a different communication style as a flaw.
What Mirror does
The founder uploads a recording after the meeting. Mirror does not join the call. It transcribes the conversation, identifies which speaker is the founder, and calculates a small set of measurements in code: speaking time, interruptions, filler words and how long it took to reach the main point.
The model then reads the transcript alongside those measurements. It highlights what worked and where the conversation became less clear. For each useful moment, the founder can see what they said, a more direct version of that line, and a button that opens the recording at the right place.
What I learned from one user
Starting with synthetic respondents
I had one founder whose meetings I could study closely. Before asking more people for their time, I also made five AI-generated founder profiles with different communication styles and used them to test my early ideas about feedback.
They were useful for generating questions, but they agreed with each other too often to count as evidence. Clarity and tone came out on top — interruptions were a distant last. I kept interruptions in the product because they can reveal a pattern that is hard to notice while you are speaking.
The real founder made the decisions that mattered. He uploaded his meetings and told me when the feedback missed the point. His reactions led to the rewritten lines, the link to the exact moment in the recording, speaker recognition, and the removal of scores.
Why I removed the scores
An early version gave a meeting 9.1 out of 10 for clarity. On the same screen, the written analysis described a long opening, no agenda and an ending without a summary. He also couldn't tell what a 7 for interruptions or a minus 1 meant.
I could have worked on the formula. But even a better formula would have left him with a rating instead of a useful next step. Kluger and DeNisi’s 1996 review of feedback helped me think about this: feedback can be less useful when it draws attention away from the task itself. In this case, “Clarity: 9.1” gave him very little to work with. “The investor asked about expenses, and you gave the number after three explanations” pointed to something he could replay and change.
I removed the scores. Mirror still shows measurements that can be checked, such as how often something happened or what share of the meeting it took. Instead of a clarity rating, it might say that the main point arrived in the ninth minute. If that observation is wrong, we can find out. If it is right, the founder knows where to start.
The old version: a 9.1 for clarity, under a summary of a meeting that was hard to follow.
Deciding what the model should do
The hardest design work was not in the interface
My first version asked one prompt to count, interpret and coach. It was doing too much, and some of its counts were wrong. I moved the measurements into Python and gave the model the work that requires interpretation. I also split the model’s work into separate calls. At one point there were three; one drafted a message after the meeting, but real use gave me no good reason to keep it. There are now two.
The timestamp bug made the division especially clear. A “Watch this moment” button opened the recording at 21:49, although the quoted line had been said about five minutes earlier. I revised the prompt twice. That did not solve it: I had not given the model the exact timestamp for the line, so it was effectively guessing.
The fix was to find the line in the transcript and take its time from there. Code now handles that lookup. The model can focus on why the moment matters and how the founder might phrase it differently.
What the model must never do
In one analysis the coaching described the counterpart as British. Nothing in the transcript said so. The model had filled a gap with something plausible, and a founder reading it would have no way to know which parts were observed and which were invented.
Two things changed. The prompt now forbids naming a nationality that was not stated. A check runs after every analysis and flags nationality terms in the coaching text, so I see it in the logs rather than in a user's report. The same rule applies to rewrites: a suggested line may reorder what the founder said, but it may not add a fact they never said, including a number.
The main design decision was what goes to code. And what goes to the model.
One pattern at a time
An analysis of a single meeting is a report. What makes it coaching is what happens across meetings.
Every analysis ends with one dominant pattern: talk time, interruptions, clarity or tone. The choice is made in code, not by the model. Each candidate is scored from the measurements, and the highest one is returned only if it clears a threshold. When nothing stands out, there is no pattern, and the product says nothing rather than inventing a theme.
Once a pattern repeats across meetings, it becomes a focus area on the dashboard, with one recommendation and the reason it works. The same name then appears on every meeting card where that pattern shows up, so the founder sees one phrase in three places instead of three descriptions of the same habit.
A founder with twelve things to fix changes nothing. A founder with one thing to watch for can hear himself doing it in the next meeting. Progress is written as a sentence, not drawn as a chart, for the same reason the scores were removed: a chart of a shifting habit implies a precision the measurements do not have.
Finding the founder’s voice
A transcript can label people Speaker A and Speaker B, but those labels do not tell Mirror which one to coach. Getting that wrong would make the whole analysis useless.
I considered asking the founder to pick their speaker after every upload. It adds a question to every meeting and still does not help when four people are on the call. Instead, they record a short voice sample once, which Mirror uses to identify them in later meetings. I am still building the fallback for recordings where it cannot make a confident match.
Voice enrollment: setup, a 30-second recording, analysis, confirmation. The voice profile is then available in Settings, where it can be re-recorded or deleted.
The moment card
The interface started with one sentence from a user
When the founder first saw Mirror’s recommendations, he said they were too general. He wanted to see the exact thing he had said and what might have worked better in that conversation.
That became the main piece of the interface: a card with his quote, a suggested rewrite under “Stronger here,” and a button to watch that moment. He remembers meetings visually, so being able to return to the recording matters as much as reading the transcript.
I also wanted the product to show when something went well. Those moments have a quieter “This worked” treatment. Coaching should not make every meeting look like a list of mistakes.
What I need to learn next
This founder has used Mirror with real meetings for several months. I have learned a great deal from watching where it helps him and where it doesn't. He is still one person.
I am now looking for five beta testers, which is about as many as I can support on my own. I am not expecting meaningful statistics from five people. The question I want to answer is simpler: after trying Mirror with one meeting, will any of them choose to bring back a second?
There is no before-and-after chart here. The only numbers I could easily put into one are the scores I removed, and they would give a misleading picture of what I have learned so far.
