The last commit of the day is titled after its own failure
Nine commits, one day, about 6,800 lines. The recorder shipped with no interface, then with an interface on four pages while the button stayed dead on forty others, then with a library page that had been routed before it existed.
The call recorder was built on 2026-07-25, in nine commits between 15:33 and 22:37. Roughly 6,800 lines in one day.
It records a call, transcribes it, summarises it, and writes the result back to the CRM against the right contact. What makes it interesting technically is that it does speaker labelling without a speaker-identification model. Your microphone and the meeting's audio are captured as two separate streams, transcribed separately, and interleaved by timestamp. Whoever was on which stream tells you who was talking. A similarity pass drops the echo of the prospect's voice coming back through your own speakers.
The two recorders start a fraction of a second apart, so each carries its own clock offset, and the server corrects for the skew before merging. Audio never touches disk: it lives in the worker's memory between upload and transcription and is discarded either way. Only the transcript survives.
Now the part worth reading, which is the order in which nine commits repaired each other.
Four hundred and twenty-four minutes of self-inflicted repair
The first commit, at 15:33, is the entire recording backend. Transcription, summarisation, write-back. It shipped with no interface at all. No button to start a recording, no page to see one, and notifications pointing at a detail route that did not exist. For two hours the system could send you a notification about a call, and clicking it produced a not-found page.
The second commit, at 17:31, adds the interface and says so in its opening line: this puts a user interface in front of the backend shipped earlier, which had no launcher, no page, and notifications pointing at a route that did not exist.
That interface then shipped the recorder script on four templates, and the commit that fixed it counts forty others where it was missing. The launcher button was registered as a generic action, and the action system deliberately does nothing when it encounters an action it does not recognise, so on those forty pages the record button was a silently dead control. Not an error. Nothing.
The fix, at 21:04, moves the script into the base template and adds a test asserting it appears there and nowhere else, so that a well-meaning future re-addition on a single page fails loudly.
At 21:27, the calls library page. Its opening note is that the route had already been listed in the host router's application prefixes, pointing at a page that did not exist. The routing for a page shipped before the page.
And the last commit of the day, at 22:37, is titled "wire the recorder into the app it shipped into." It opens: the capture pipeline worked, the integration did not, and five things were actively broken rather than merely missing.
I have a lot of affection for that title. It is a commit named after its own author's mistake, written by the person who made it, at half past ten at night.
The workaround that hid data from eight queries
Among those five things is the best bug of the day.
When the worker finished a recording, it wrote an entry to the activity log. It recorded the type as "meeting" rather than "call". The reason, per the commit, is that the meeting type had an icon and the call type did not, so writing it as a meeting avoided a blank space in the interface.
That cosmetic workaround hid every recorded call from eight separate queries: the calls-made metric, the connected-calls metric, the leaderboard in two places, a rollup behind the engagement filters, and the report metric registry.
A missing icon caused a reporting blackout. Somebody chose the wrong enum value to avoid an ugly gap in a list, and in doing so removed an entire activity type from the analytics of the product.
The fix ships a backfill and, admirably, warns about its own consequence: expect a visible jump in call metrics and leaderboard standings, it is correct, and it will read to users like a data change.
While fixing that, the same commit found a dashboard button that had been dead for under twenty-four hours because a script was missing its security token, discovered entirely by accident on the way past.
There is one more, and it is a good demonstration of why this feature needed so much repair. Recordings started from a contact page were being saved without an associated company. And the company-level launcher had been writing company-scoped recordings since the interface shipped, while nothing displayed them, because the filter that would have shown them had no callers. Two halves of a feature, each waiting for the other, neither reporting a problem.
The things they refused to build
The settings commit contains a list of features cut as theatre, and it is the most useful paragraph in the whole day.
A configurable default title template, cut because the launcher already knows what the call is about and will beat any template a user writes. Automatic task creation without a confirmation step, cut because that confirmation is the only thing standing between a hallucinated next step and a real task on someone's list. Microphone device selection, cut because the browser will not tell you the names of the devices until after permission is granted, so the setting could never render usefully on a settings page.
Each of those is a feature a reasonable person would have specified. Each was refused for a concrete reason discovered while building.
The double-escape problem is my favourite piece of care in the whole thing. The application closes overlays by removing them from the page, which means a close handler never fires, which means a naive recorder would leave the microphone running with no window to stop it. Six separate hooks converge on one idempotent stop. And the one event deliberately excluded is the tab losing focus, because switching to the meeting is the entire use case.
They tested it by ripping the overlay out the way the application does and confirming the microphone stopped and the recording still uploaded. That is the correct way to test a teardown path: not by triggering it politely, but by doing the violent thing your own code does elsewhere.
— DealArena Team