Release day: shipping 1.3.0 and planning what's next

Overview

Mike and Nick held their regular Monday working session, which doubled as a live release meeting for talat 1.3.0. They walked the regression test plan line by line, tested the release candidate on Mac and Windows, prepared the changelog, and published the release. The second half of the call set the sequencing for the next pieces of work: the calendar and notifications branch, the referral scheme, and hosted talat.

Key discussion points

Release prep and build issues

Prepping the release candidate hit a blocked build: the check pass was failing on lint errors in a couple of new UI files. Those were hotfixed for the 1.3.0 release.
A test release candidate was built for both Mac and Windows deliberately, given how big this release is.
Windows builds have been noticeably slow recently; Mac finished well ahead of Windows on both the RC and the final builds.
Nick found that walking through the regression document out loud was unusually valuable and suggested doing it for every release.

Regression doc walkthrough: 1.3.0 contents

Auto-start and auto-stop rewrite. The entire auto-stop decision tree has been rewritten; eligibility is now computed at claim time. Manually starting a recording will never auto-stop it.
Conferencing-app narrowing. Extracted from the long-running calendar branch. If Zoom grabs the mic, a Teams calendar invite is no longer considered a valid binding candidate: if you are using the Zoom app, you cannot possibly be on a Teams call. Browsers remain wildcards; a browser doesn't rule anything out. This is purely a narrowing mechanism.
Two macOS calendar fixes. Hopefully resolves the duplicated and recurring event issue one user reported; it appeared fixed for Nick on Apple Calendar.
Speaker attribution. An optional setting to auto-lock the system channel if it starts with one person in it, plus optimistic painting of a single member from speech start (a tentative label shown immediately when a channel is locked with one person). Also a reword of the system-channel-lock setting copy, which had originally been written badly.
Audio processing. An "ignore very quiet audio" setting (opt-in), aimed at drift from a call happening in another room. It uses a fixed cutoff of −54 dBFS, which Nick called "an incredibly low floor"; the value is written to settings and sanitised, so power users could tune it at their own risk. It lives under Transcription then Sensitivity, not Audio, which confused Nick.
Summary and LLM. Mike's fixes: the regenerate dropdown at the bottom of the summary page was going off-screen (it now flips to the top, the same logic as the left-to-right flip), plus markdown streaming previews and rendering summary markdown as styled output. Mike also removed the flashing cursor while streaming.
Dictation cleanup guard. A hard-coded, non-editable suffix always appended to the user's prompt, essentially "don't try to be helpful, just do exactly what you're told."
Onboarding and trial. A launch-at-login onboarding step, and a buy link on the trial-exhausted status line. Previously that status line had no call to action at all; you had to know to click through.
Settings and devices. Settings now show the actual system default device name, prompted by a community member they'd struggled to help because "system default" gave no indication of what the current default actually was.
Bug fixes. Calendar event identifiers were being shared across recurring occurrences on Apple calendars.

Risk areas identified

The auto-stop rewrite's edge cases rather than the happy path, specifically auto-update plus resume, where boot recovery resume recomputes eligibility from scratch. Nick's mitigation reasoning: "this is the opposite of a data-loss scenario. All this is is we might not stop a recording."
The change to how calendar IDs are formed for recurring events means a previously deleted occurrence can reappear once, within a finite window. Flagged for the changelog; noted it could temporarily worsen things for anyone who has manually deleted duplicates.
The speaker-attribution auto-lock and the mic floor are both opt-in, so considered low risk. The mic floor's weakness is that the cutoff is arbitrary, and mics with strong hardware pre-amplification may still exceed it. Real-world data needed.

Live testing performed

Nick tested auto-start and auto-stop on Windows: manually started a recording, let Chrome briefly grab the mic, stopped the Chrome test, and the recording correctly did not auto-stop. The inverse (Chrome starting triggers auto-start, Chrome stopping triggers auto-stop) also worked.
Confirmed the Apple Calendar forthcoming-meetings list looked correct with all recurring instances.
Confirmed "ignore very quiet audio" doesn't break normal speech pickup.
Confirmed summary generation and markdown rendering work; screenshots were captured as evidence via talat (paste from clipboard works, including in focus mode after an initial false alarm).
After publishing, Nick live-updated mid-call. Auto-resume correctly inferred auto-stop conditions from the current live mic set (the baseline active apps included Chrome). Residual edge case: manual start, then a known app takes the mic, then a restart for update, then the known app drops out, would now stop the meeting; a possible fix is persisting that state on the database record.

Automatic gain control

Nick has a change open to expose automatic gain control (from the echo-cancellation stack) as an opt-in setting. It boosts the mic when needed, but previously made word error rates jumpy across the regression tests.
The open question is whether that's an artefact of synthetic tests with perfect audio: "we need real-world evidence. I think we probably do just want to add it as an opt-in setting and say, look, this may affect transcript quality."

Changelog

A new "notable changes" section was introduced, a place to flag behaviour-affecting changes without forcing a major version bump. The auto-start and auto-stop change went in there.
An early draft of the changelog misrepresented the emphasis of one feature and used clumsy phrasing, corrected before publishing. Nick liked the callout style but was unsure about the pink dot; they agreed it will look better once there are multiple entries.

Referral scheme

Mike is glad to have insights and the referral scheme largely done; both are functionally sound and now mostly UI work unless the backend needs to change. The referral scheme went through a lot of code-review passes in the end.
The complexity was all in the edge cases: what happens on refund, on the other user's refund mid-vesting, refund then resubscribe, cancel then resubscribe while people are still vesting.
Open concern: giving the referee their first month free. Nick worries that charging $0 may cause Stripe to drop the card-details input, historically true with static buy links and coupons, but possibly different now checkout sessions are controlled programmatically. Mike believes card details were still required in the sandbox, and noted a subscription should force card capture regardless.
Worst case if card capture is skipped is minimal: only the payment processing fee, so not a real concern.
Testing approach: durations can be changed and the scheduled job fired manually.

Calendar and notifications branch (next release)

Notifications have been redesigned as two layers, an information row plus an action bar at the bottom, allowing more actions. They are bigger as a result.
The in-app UI now shows that a recording has been linked to a calendar event, with options to unlink (back to a plain recording) or relink to a different overlapping meeting. The philosophy: "the notification tries to help you do the right thing early, but if you've done the wrong thing you should be able to correct it from the page."
Unlink and relink have tricky database implications; an early version wiped all participants on unlink, which is wrong if someone has already spoken and been confirmed.
Link and unlink actions can now be undone via a toast (a short window). Toasts are next on Nick's list because they don't indicate how long they live.
Known gap: when settings are set to "prompt" and two meetings could match, the Choose button opens the app's picker rather than a dropdown, partly because of a long-standing bug where clicking any notification focuses the talat window anyway.
Nick's main ask of Mike is fresh eyes on the UX and terminology, especially notification wording, which he has reworked many times: "notifications are almost unexpected to the user. If you're only giving them eight seconds by default to make a decision, it needs to be extremely clear what you're asking and why."

Hosted talat

Fully deployed in all environments and just sitting there; the feeling is they need to stop putting it off.
The plan: launch as a free beta with capped usage. A usage ledger already exists; lazily create a row with a fixed credit allocation the first time a user is seen during the beta, so usage is capped and nobody can run up an unbounded bill.

Product ideas and backlog

Prompts settings section. Mirroring the LLMs section. It would allow saved summary prompts and dictation prompts, multiples of each. Nick: "that unlocks a lot." Combined with "regenerate with this model and this prompt," it becomes the building blocks of what most people want from actions and workflows, even without building the automation, for example saying mid-call "when this ends, generate with this model and prompt."
Settings simplification. Both agreed settings are hard to navigate; Nick "constantly gets confused as to where I'm going to find a given setting." Mike's proposal: a very user-friendly main settings screen with a click-through to advanced settings so nothing is lost. Nick suggested exposing settings via a command-K search. The acknowledged tension: if it's a thing you should be able to customise, they want to let you, but it's hard to cover every scenario and hard for people to understand. Mike: as engineers they're used to dense settings screens and need to put themselves in a standard user's shoes.
Assign speakers while still speaking. A suggestion from the roadmap. Mike likes it but flags the logic: keep the person assigned for the whole utterance, then run the normal logic on completion. Nick noted it requires a very actively engaged user, which isn't the expectation, plus complications around detected splits. Agreed it's not a priority for now.
Focus mode. Still not working well for Nick, and a community member raised the same. Nick can't quite articulate what's missing but wants something like a mini mode: a small pop-out (possibly from the tray menu) showing the last few things said, flashed up and dismissed. The current annoyance is that entering focus mode from a sized window makes the window too big.
Dictation while in a meeting. Nick wanted to dictate to the assistant mid-call and couldn't: "there's nothing that would stop us, except that we've implemented them as completely isolated things."
Transcript fragmentation. Nick showed a screenshot of one of Mike's contributions rendered as a long, vertically fragmented block, making it much less coherent. It's worse on a locked one-to-one, where more could be done to merge.
Screenshots in the automation surface. Screenshots currently only surface as extracted text in the transcript, with no path exposed. Both agreed the automation surface should expose the on-disk path so an agent can retrieve the actual image after a meeting. The local model is multimodal and could describe images, but Mike thinks that would be too expensive.
Automation-surface hardening. Nick has work open for tightening the controls, informed by two prototype apps he's been building. Particularly relevant given the plan to expose start and stop recording, which is quite a big control surface to expose to an agent.
LLM lifecycle. Dynamically size the LLM context based on meeting length at boot; don't reload if it's already loaded and big enough, scrap and reload if it's too tight. Move to always lazy-loading and unloading promptly when not needed, removing an option entirely. Caveat: dictation may cause contention on the chip, so "we just need to try it and see how it feels." Current memory requests are ultra-conservative (around an eighth of RAM) because the LLM used to hang around; with lazy load and unload, current memory pressure becomes a much better indicator and they could be more aggressive. Nick also wants to re-evaluate blocking 8GB machines: "I don't see any reason you can't summarise on an 8-gig machine."

Growth

Organic growth is up week on week.
Nick reflected on the gap to larger indie accounts he follows, one of whom recently posted numbers orders of magnitude beyond theirs: "that is the gap." Mike: "the chasm." Both agreed the direction of travel is what matters.
Repo hygiene flagged: they're overdue another consolidation phase, with a few hundred open issues and a stack of open PRs, and have lost the handle on it again.

Decisions made

Ship 1.3.0. After RC testing on Mac and Windows, the changelog was finalised and the release published live during the call.
Add a "notable changes" section to changelogs for behaviour-affecting changes, in lieu of major version bumps. The manual-start and auto-stop change goes in it.
Ship the calendar and notifications work as its own release. Mike: "I think it should be its own release, for sure." Sequencing: calendar first, even if it means a quick follow-up release.
Prioritise the referral scheme over insights and hosted talat as the next major workstream after calendar; both independently landed on it.
Swap review responsibilities. Mike takes the calendar and notifications branch (fresh eyes on UX, wording, and the link/unlink flows); Nick takes the referral scheme.
Automatic gain control ships as an opt-in setting with a quality caveat, to gather real-world data rather than relying on synthetic tests.
Hosted talat launches as a free beta with lazily-created, capped credit ledger rows.
Move to always lazy-loading and unloading the LLM, removing the option. Nick: "I simply don't see that that needs to be an option. It's a handful of seconds over a massively latent process anyway." Subject to testing dictation contention.

Additional notes

The local LLM lazy-loads correctly whether the default summariser is an external model or the built-in one; re-summarising with the built-in model after an external one works the same as the other way around.
Confirmed behaviour: generating a summary only drives actions and chapters the first time, when none exist. There is a separate option to generate chapters, but not actions.
Referral credits apply to the specified products (one product with two prices, plus the lifetime licence), so they're redeemable against a lifetime licence as well as a subscription.
A "models loading failed" message was identified as the wrong error, already fixed in a later version, and likely trumping the upgrade notification on the status line, meaning affected users can't see the update that would fix it. A broader concern was raised about competing priorities on the status-line call to action.