The experiment: replace a $100 subscription, or at least dent it
Hachman has used Otter for years and says he pays about $100 a year. That detail is in his own account, not in the search material. He didn't want a clone. He wanted a competitor that could do some of the same jobs. His employer pays for business licenses to both ChatGPT and Claude. He says Claude seems to be the favorite among coders, but he went with ChatGPT because he already knew it.
He ran two parallel attempts:
- HachTalk was built in a ChatGPT Project, which he says uses a "Pro" model. Its memory stayed within that project.
- HachTalk Astra was built in a regular chat on what the interface called the "Astra" model. It could draw on what ChatGPT knew from his earlier chats.
ChatGPT told him the Pro model was better at deep reasoning and Astra was faster and more conversational. That is the chatbot describing itself. Nobody benchmarked it. The model names are also as they appeared in his interface, so don't map them to other products.
The prompt
Both attempts used one prompt. It asked for a Windows app that:
- runs locally and auto-detects local hardware to use its resources;
- ships as an executable, with versions for both x86 and ARM;
- accepts prerecorded audio and processes live audio;
- lets you tag speakers and saves those speaker models for later chats;
- syncs playback to highlighted text, so clicking the text starts playback from that point; and
- breaks the transcript into paragraphs with proper punctuation.
That's a long feature list for a first prompt. These are only the features he requested. Nothing in his account shows they were all delivered. He says one build showed speaker identification and tagging in the interface, but the feature didn't actually work.
What happened
Neither attempt worked at first. Both started by producing a non-functional "prototype" meant to be compiled by the user, which was not what he wanted. He demanded an executable instead.
His timings:
| Build | Prototype | Executable |
|---|---|---|
| HachTalk (Pro) | 4 min 43 sec | 18 min 39 sec |
| HachTalk Astra | 3 min 3 sec | 9 min 49 sec |
These are one person's observations from two attempts, not a general estimate of how long AI app development takes.
The two apps looked quite different. Astra's interface was extremely basic, "barely recognizable as an app" in his words. The Pro build looked more sophisticated and had adjustable options. Astra also shipped a "Third Party Notices" file listing the components and models it used. The Pro build didn't. He doesn't say what those components were, so there's no way to judge what either app bundled or what licensing obligations came with it.
Troubleshooting by screenshot
Both builds threw errors he didn't understand. His fix was to screenshot the error and tell ChatGPT to fix it. It did, "sort of." After a few rounds he had code that transcribed his own speech and an audio file.
The problems didn't stop there:
- He wanted better paragraphing and punctuation. The app delivered it, then reverted to the older, imprecise transcription. That was another bug and took a minute or two to fix.
- One build accepted only MP3 files. He had to say explicitly that he wanted other formats.
- Each iteration meant a small download.
HachTalk reached version 0.2.3. He gave up on HachTalk Astra. He doesn't report transcription accuracy figures, and he doesn't say whether the app is distributed to anyone else.
The ARM requirement
The prompt asked for x86 and ARM versions, and that's easy to type and hard to deliver. Microsoft's Windows on Arm documentation says running under emulation is a good start, but native performance gains come when you rebuild to add Arm support. Microsoft's guide says Arm-native support lets an app take advantage of native performance gains.
The most likely reason an Arm64 build fails is a dependency that isn't available for ARM64. That matters here because a transcription app probably leans on speech models and runtime libraries. Hachman doesn't say which ones his builds used. Microsoft's guide also says emulation supports only user-mode code and not drivers, so kernel-mode components must be compiled as Arm64.
If you ask an AI for "both architectures," you can check the result yourself. Microsoft's guide offers an optional check: open a terminal in the project directory in PowerShell. From there you run Microsoft's dumpbin /headers command on the built executable. The guide says to confirm the file header shows an AA64 machine, meaning ARM64. That step is written for developers building in Visual Studio. A user handed only a finished executable would need a PE-header inspection tool or a real Arm device. Hachman doesn't say he ran any such check, so whether his builds work natively on Arm is unknown.
Microsoft also says Arm builds should be tested on real hardware or a VM. It notes that Windows 11 picks the best available version when you install from the Microsoft Store. That's a distribution matter and doesn't apply to a hobby build.
Practical lessons
These are my deductions from his experience, not a tutorial he wrote or one I tested:
- Ask for an executable up front. The default behavior in his experiment was source code to compile.
- List your requirements, including the boring ones. The MP3-only limit shows that an unstated input format becomes whatever the model picks.
- Describe failures concretely. Pasting a screenshot of the error worked well enough for him. Adding what you did just before it appeared would probably help further.
- Test every promised feature. A launched app isn't a verified one. A speaker-tagging button that does nothing counts as a failure.
- Check for regressions after each change. His punctuation fix undid earlier progress.
- Keep an eye on what's inside. Astra's third-party notices file is a good sign. Without a list of bundled components, you can't tell what's in the app or what licenses apply.
What this doesn't tell us
His account has real limits.
- It's a single anecdote with no controlled comparison and no accuracy testing against Otter.
- It doesn't verify that audio stays on the device. He asked for local processing, but the account never shows whether any network service was needed. For meeting recordings, assume nothing until you've tested it, for example by watching network activity.
- It includes no security or privacy review of the generated code.
- It doesn't name the language, the speech engine or the test hardware.
The article is also a newsletter column. It's candid, but it's an enthusiast's take rather than an engineering evaluation. Hachman himself says the apps have "the look and feel of a microwave dinner."
Verdict
Hachman's own conclusion is that vibe-coding takes a down payment of time, focus and tokens. He describes working apps that are usable but rough, and he's undecided about dropping Otter. The tradeoff he lands on is reasonable: you can get software shaped exactly to your needs, but you spend your time specifying, testing and debugging it. For a one-off utility that's often worth it. For a tool that handles sensitive recordings and has to run reliably on both x64 and Arm PCs, a $100 subscription may still be the cheaper option.