There are excellent voice dictation tools for Windows and Mac. Wispr Flow, VoiceOS and dozens of others. You hold a key, you speak, and the text appears wherever you are working. In English they are impressive. In Greek, they are not.

This is the story of a tool we built because it did not exist.

The problem was not accuracy

You would expect the issue to be a few wrong words. It was not.

The wrong language entirely. Time and again a purely Greek sentence was recognized as Spanish, Chinese or Russian. The result was not a wrong word, it was gibberish: a pile of characters that said absolutely nothing. There was nothing to correct; there was garbage to delete before starting over. A tool that fails like that is not inaccurate, it is useless.

Language mixing. A Greek professional’s speech is mostly Greek, with scattered English words in between: Plesk, Supabase, Next.js, deploy, commit. Commercial tools would either “correct” the English words into wrong Greek ones, or flip the whole sentence into English.

Wrong punctuation. The Greek question mark ”;” was almost never placed correctly. Sentences came out as endless runs of words with plain periods.

No customization. Tool names, technical terms, client names: never right, and no way to teach them to the program.

Locked to one engine. Each tool uses a single recognition engine. If it does not suit you, there is no alternative.

The goal was simple to state and hard to build: a tool that genuinely understands Greek, along with the Greek-plus-English mix, and gets the punctuation right.

Two stages, not one clever trick

VoiceType lives in the Windows system tray. You hold a key, speak, release it, and the text types itself into whatever app you are working in: Word, a browser, a code editor, chat, anywhere.

What makes it different is not some cleverness, it is a two-stage architecture.

Stage one, listening. Audio goes through a recognition engine of your choice, and four are supported:

  • ElevenLabs Scribe, which in practice turned out to be the best for Greek.
  • Azure Speech, fast and stable, locked to el-GR.
  • OpenAI, with gpt-4o-transcribe, gpt-4o-mini-transcribe and whisper-1.
  • Local Whisper, which runs on your own machine, offline and with no per-word cost.

You can bind two independent keys, each with its own engine. One for fast local recognition, one for the most accurate cloud engine.

Stage two, editing. This is the heart of it. The raw text, which usually arrives with plain periods only, passes through Claude, acting as a dictation editor built specifically for Greek. It adds correct Greek punctuation: question marks, exclamation marks, commas and capitals at sentence starts and on proper nouns. It does not translate, it keeps the English words exactly as you said them. It does not change meaning, it only cleans up. And it recognizes your personal vocabulary: if you say a term that comes out distorted, it writes it correctly.

Because “correct punctuation” means different things for different work, there is an intensity scale of 1 to 5: from very conservative, only certain periods, to very aggressive, catching every question and every emphasis.

That point deserves attention, because it explains something many people misread. Wispr Flow does not catch question marks because it “hears” better. It catches them because it adds them in post-processing, after recognition. VoiceType does the same, with the difference that the dial is in your hands.

Beyond voice to text

The tool quickly became more than that. It gained a control panel with words per minute, time saved, corrections, a consistency calendar, top apps and a cost estimate per engine.

The VoiceType control panel: a speech rate of 94 words per minute, time saved, cost estimate, consistency calendar, top apps and words per day.
At the top, the two keys with a different engine each, and the editing stage active. Below, speech rate, time saved, cost, and which apps the dictation goes into. The interface is in Greek.

In our own use the speech rate measures around 94 words per minute. You do not need to know your typing speed to see the difference: nobody types that fast. A visual waveform above the cursor while you speak, discreet, without stealing focus. Water-drop sounds on start and stop, synthesized internally. Voice commands that turn into formatting. A personal replacements dictionary. Three injection modes: paste, character-by-character typing, or copy to clipboard only.

The four hard parts

The easy part was sending audio to an API. The hard part was behaving like a real Windows program: invisible, fast, unobtrusive. That is where the real problems hid.

The stack: Python 3.13 on 64-bit, PySide6 for the UI, sounddevice for microphone capture at 16 kHz mono, the keyboard library for global hotkeys, ctypes for direct Windows API calls, and PyInstaller for the final .exe.

The cursor ran away. You pressed the key inside certain apps and focus was lost. The first guess, that the waveform overlay was to blame, was wrong. The real cause was that the keypress was also reaching the app underneath. The fix was suppress=True in the keyboard library, so the trigger key is swallowed and never reaches further down.

Truncated handles on 64-bit. The overlay persistently stole focus despite correct settings. The cause was subtle: on 64-bit Windows, window handles are pointer-sized, meaning 64-bit, but ctypes truncates them to 32 by default. Handles came out corrupted and the calls failed silently, which is the worst kind of failure. The fix was to declare the HWND type explicitly on every call. The same applied to SendInput’s INPUT struct, which had to include the full union to have the correct size on x64.

The exe forgot its settings. Once we packaged the app, every launch lost the API keys. Settings were being written next to the executable, in a folder that was not always writable. The fix was to move them to the permanent user folder, with a one-time automatic migration of the old ones and a diagnostic file confirming where it looks.

It ate the last word. You released the key and recording stopped instantly, cutting off the last syllable. The fix was a small recording tail, a few hundred milliseconds after release.

There were others, from packaging with the correct Python environment to drawing the waveform so it looked alive rather than a flat line. But these four are what separate a prototype from a tool you trust every day.

What came out of it

A personal tool that, for Greek with scattered English, produces better results than the commercial products that inspired it. Not because we are better engineers than they are, but because it solves our problem, which they had no reason to solve.

Language locking, so it does not “correct” Greek into English or the reverse. Editing with an intensity dial. Personal vocabulary. Four engines, so you pick the balance of speed, cost and accuracy without depending on a single provider. And full control, since it runs locally and the data stays on your machine.

The lesson, though, is more general, and it is the same one that comes out of MS-Tools: good general-purpose tools fail at the edges. And the edges, a second language, a specialized vocabulary, a particular punctuation, are often exactly where your work lives.

When the off-the-shelf tool does not do the job, we build one. If you have a problem no ready-made tool solves, tell me.