I built TAWK because I was tired of typing. That is the whole origin story. I spend hours every day writing messages, emails, documents, and notes. My thoughts move faster than my fingers, and I kept wishing I could just talk and have the words appear on screen. So I built the thing I wanted.

TAWK is a voice to text Mac app. You press a keyboard shortcut, speak, and your words appear wherever your cursor is. It runs entirely on your machine using OpenAI's Whisper model. There is no cloud service, no subscription, and no voice data sent to anyone's server. You buy it once for $59 at gettawk.com, and it is yours.

What follows is an honest account, rather than a polished startup narrative, of taking a personal itch and turning it into a shipped product that real people pay for. The decisions that mattered. The technical landmines I stepped on. And what I would tell anyone thinking about building their own thing.

The Decision to Build

I looked at every voice to text option on the Mac. Apple's built in dictation requires an internet connection and the accuracy is mediocre. Whisper based solutions existed, but most were command line tools or rough wrappers. The polished options were subscription based, which always felt wrong for something this simple. I wanted it to work offline, be private, cost a flat fee, and be reliable.

Nothing fit. So on a weekend, I opened my editor and started building.

The best side projects start when you cannot find the thing you need and decide to make it yourself.

The Tech Stack: Python, Whisper, and rumps

I chose Python because I know it well and because Whisper has excellent Python bindings. For the Mac menu bar interface, I used rumps, a lightweight library for building macOS status bar apps. The core flow is simple: listen for a global keyboard shortcut, record audio from the microphone, run Whisper's small model on the recording, and paste the transcribed text at the cursor position.

Whisper's "small" model hits the sweet spot between accuracy and speed. It is fast enough to feel real time on any modern Mac while being accurate enough for everyday dictation. And because it runs locally, there is zero network latency. You finish speaking and the text appears in under a second.

Why Offline First Was Nonnegotiable

People dictate private things. Emails to their partner. Journal entries. Messages to their therapist. Business strategy notes. The idea of sending all of that to a server felt fundamentally wrong. I decided early on that TAWK would process everything on device, without exceptions.

This was also a business decision. Cloud based speech to text means ongoing API costs, which means you either eat the margin or charge a subscription. Offline processing means my costs are essentially zero after the sale. That let me charge a one time fee instead of a subscription. I give up recurring revenue, the customer gets a much better deal, and the business is much simpler.

The Prototype Was Easy. The Product Was Hard.

Getting a working prototype took a weekend. Press a key, record, transcribe, paste. I used it myself for a few weeks and it worked great on my machine. Then I tried to turn it into something other people could install. That is when the real work started.

PyInstaller: The Hardest Part of Bundling

macOS apps are bundles. You cannot just tell someone to install Python, pip install a bunch of dependencies, and run a script. You need a proper .app that people can drag into their Applications folder. I used PyInstaller for this, and it was the most time consuming part of the entire project.

PyInstaller does not automatically bundle Whisper's model assets. Files like mel_filters.npz that Whisper needs at runtime were simply missing from the bundle. I had to manually specify them in the PyInstaller spec file. Then there were the PyTorch dependencies, which are massive. The initial bundle was over a gigabyte. I spent days trimming unnecessary CUDA libraries and other artifacts that are not needed on macOS.

Code Signing and Notarization

Apple requires apps to be signed and notarized before macOS will run them without scary warnings. This is reasonable from a security perspective, but it is hard for an indie developer to get right. Here is what I learned the hard way:

I spent more time on signing and notarization than on the actual voice to text functionality. This is the part people leave out when they talk about launching quickly.

The LSUIElement Discovery

For menu bar apps on macOS, you need to set LSUIElement: true in your Info.plist. Without it, your app shows up in the Dock and the Cmd+Tab switcher, which is wrong for a utility that should live quietly in the menu bar. I also learned that calling setActivationPolicy_(Accessory) after showing a modal window causes focus and rendering issues. The fix was to let LSUIElement handle it from the start and not touch the activation policy at runtime.

The Keyboard Event Gotcha

TAWK pastes transcribed text by simulating keyboard events using CGEventPost. What I did not realize is that CGEventPost inherits the current modifier key state. So if the user was holding Shift when they triggered TAWK, the pasted text would come out all caps or with weird characters. The fix was to explicitly clear modifier flags with CGEventSetFlags(event, 0) before posting each keystroke. A tiny detail that took hours to debug.

Going From a Working Prototype to a Released Product

The gap between a working prototype and a shippable product is enormous. Here is everything I had to build beyond the core functionality:

Each of these is straightforward in isolation. Together, they represent weeks of work that have nothing to do with voice to text and everything to do with being a real product.

The One Time Payment Decision

The SaaS playbook says to charge monthly for recurring revenue and higher lifetime value. I understand the math. But TAWK is a utility that does one thing and does not use a server. There are no ongoing costs on my end. Charging people $8 a month for something that runs entirely on their hardware felt dishonest.

So I made it a one time purchase, $59 today. It is a real price, enough that people take the product seriously, and buyers own it forever instead of renting it every month. That simplicity has value that does not show up in a revenue model spreadsheet.

A subscription is the wrong model for some products. Some tools are better bought once and left to do their job.

What I Would Tell Anyone Building a Side Project

Build for yourself first. The strongest products come from genuine personal need. You are your own best user because you have real context, real frustration, and real taste about what the solution should feel like.

Release early, even if it is rough. The first version of TAWK was rough. The menu bar icon was wrong. The onboarding was confusing. It still worked. Getting real users on a rough product teaches you more in a week than perfecting it in a vacuum for a month.

The "last mile" is 80 percent of the work. Getting something working on your machine is maybe 20 percent of the project. Code signing, notarization, licensing, landing pages, support infrastructure, and distribution are the other 80 percent. Budget for it.

Pick boring technology you know. I built TAWK in Python, which is not the "right" language for a Mac app. Swift would have been more native. But I know Python deeply, and that let me move fast. When the goal is to release a working product, familiarity usually matters more than elegance.

Add logging early. Add file based logging from day one. When a user reports a bug, you need to be able to see what happened. For distributed desktop apps, this is essential.

Keep it simple. TAWK does one thing: press a key, speak, see text. Every feature request I get asks me to add something that would make it more complicated. I say no to almost all of them. Most of the product's value comes from that simplicity.

Where TAWK Is Today

TAWK is live at gettawk.com. It is signed, notarized, and running on Macs around the world. I still use it every day. Every time I dictate a message or a note or a paragraph of this blog post, I am using my own product. That feedback loop is the reason it keeps getting better.

Building TAWK reminded me of something I already knew but sometimes forget in my day job scaling a large company: the best things start small, start personal, and start with someone scratching their own itch. If you have an idea for something you wish existed, build a working version before writing a long plan for it.