The problem with “free” transcription

Online transcription is rarely free in the way that counts. You pay with your audio. It gets uploaded, processed on someone’s servers, and often retained, sometimes to train the next version of their model. For a casual voice memo, fine, maybe you do not care. For anything confidential, you should, because the moment audio leaves your device you have lost control of it for good.

The promise I wanted to make and keep was plain: your audio never leaves your phone, and the app never uploads your recordings or transcriptions anywhere. You can only say that with a straight face if the app has no server in the loop at all. So it does not. Here, the missing backend is not a limitation you apologize for. It is the whole point of the app.

Whisper on a phone

The thing that makes this possible is Whisper, the open speech model that is startlingly good across languages. Private Transcribe covers 99+ languages through multilingual models, which is a feature you could never offer cheaply if every minute of audio had to round-trip through your own servers. On the device, languages are free.

The engineering problem, as with any on-device AI, is fitting a capable model onto a phone without setting it on fire. Whisper ships in sizes, and the size you pick is a straight trade between speed, accuracy, and storage. Rather than choose for the user, I put that decision in their hands as a quality tier:

• Tiny (75 MB): fastest, fine for quick notes where rough accuracy is enough.
• Base (142 MB): a balanced default that suits most people.
• Small (466 MB): clearly better for recordings that matter.
• Medium (1.5 GB): professional-grade accuracy for when it really counts.

Someone on an older phone who wants speed grabs Tiny. Someone transcribing a crucial interview on a newer device picks Medium and waits a bit longer for a cleaner result. Handing users the dial, with a sensible default already chosen, beats pretending one size fits everyone. People know their own situation better than I ever could from the other side of a screen.

The app is the part around the model

The model is the engine. The app is everything wrapped around it, and that wrapper is where most of the product work lives:

• Tap to record with real-time progress, so transcription feels alive instead of like staring into a black box hoping something is happening.
• Local storage of every transcription, with search, so you can find that note from three weeks ago without scrolling to the end of time.
• Sharing for the moments you do want a transcript to leave, on your terms, by a deliberate tap, never on its own.
• A calm dark interface that is easy on the eyes over long blocks of text.

A surprising share of “AI app” work is precisely this unglamorous plumbing: making the model’s output findable, usable, and trustworthy. The intelligence is table stakes now. The product is the wrapper, and a brilliant model behind a miserable interface is a brilliant model nobody opens twice.

The unglamorous edges

Real recordings are a mess. People pause, ramble, and record for forty minutes straight. A toy demo transcribes ten clean seconds. A real app has to chew through long audio without running the phone out of memory, show honest progress on a file that takes a while, and never lose a transcription because the app slipped into the background. None of that is exciting to build, and all of it is the gap between a demo and something people trust with their week.

Where vibe coding fit

The AI assistant was a real force multiplier on the surrounding app: the recording screen, the progress UI, the local database with search, the download and storage management, the share flow. That is well-trodden ground it could scaffold quickly, which freed me up for the parts that mattered.

What stayed on me was the careful work: running Whisper efficiently on the device, handling long recordings without choking on memory, and, above all, making sure the privacy promise held end to end, with no sneaky analytics call quietly shipping audio off the phone. When your entire pitch is privacy, the privacy has to be real, and that is the kind of thing you verify by reading every line yourself instead of trusting whatever the assistant generated.

Why on-device was worth the extra pain

Building this on the device was harder than gluing together a cloud API would have been. There was no shortcut, no someone-else’s-server to quietly hand the difficult part to. That difficulty is the moat. Anyone can wrap a transcription API in a weekend, and a thousand people already have, which is why those apps all blur into one. Almost nobody ships something that truly keeps your audio on your phone, because it is more work and there is no per-minute usage to bill at the end. The hard path turned out to be the defensible one, and the privacy that came with it is the reason someone picks this app over the dozen cloud clones ranked above it in search.

Lessons

• Privacy is a feature you can build a whole product around, but only if you mean it in the architecture. “On-device” is a promise you earn in the code, not a badge you paste on the listing.
• Expose the real trade-off. Speed versus accuracy is personal, so let users pick their tier instead of deciding for them.
• The wrapper is the product. Search, storage, sharing, and a quiet interface are what turn a model into something people reach for daily.

Private Transcribe follows a pattern in the things I build: take an AI capability everyone assumes needs the cloud, and show it can run privately in your pocket. I did the same for chat in how I built an offline AI chat app, and for something lighter I went the other way entirely with a capybara arcade game.

Why a casual game

Utility apps solve a problem. Casual games create a feeling. Those are different design jobs, and I wanted reps in the second one. The bar is sneaky, too. The gameplay is simple, and simple has nowhere to hide. If the hop does not feel good, there is no feature list to distract from it and no settings screen to get lost in. The core loop is all you have, naked and exposed.

The pitch fits in a breath, which is the point. You are a capybara, the world is a wall of cars, trucks, buses, trains, and rivers, and you hop forward as far as you can. Cute character, instant understanding, one thumb. A five-year-old and a fifty-year-old both get it in the first second.

Feel is everything

In a utility app, “it works” is the finish line. In a game, “it works” is the floor. Feel is the ceiling, and I poured a wildly disproportionate amount of time into things no spec sheet would ever list:

• The hop. Its timing, the little arc, the snap onto the next tile, the tiny squash on landing. That one animation decides most of whether the game feels good or cheap.
• Readability. You have to see instantly where it is safe to land. Lane spacing, hazard timing, and color all exist to make that obvious, because a death that feels unfair makes people quit, and a death that feels earned makes them tap retry.
• The difficulty ramp. Gentle enough to start, mean enough that “one more try” gets its hooks in you. The curve has to feel fair the whole way up.

You cannot spec your way to good feel. You build it, play it a hundred times, nudge a single number, and play it a hundred more. That loop is where most of the real work lives, and there is no way around it. This is also where the AI hit its ceiling, which I will come back to.

The eagle: killing the “just stand still” exploit

Every endless hopper has the same flaw. Players figure out they can stop moving and sit there, perfectly safe, forever. All the tension drains out. My fix is a threat wired straight into the design: linger too long and an eagle drops out of the sky and carries you off. Keep moving or else.

Tiny mechanic, huge effect. It deletes the safe option, holds the tension steady, and quietly rewrites the game from “dodge hazards when you feel like it” into “always be moving, manage the danger as it comes.” The best game design is often a single rule that pushes players toward the behavior you want without a tutorial spelling it out. The eagle never explains itself. It teaches you once, and you never stand still again.

Coins, characters, and a reason to come back

A high score gets someone to play once. Progression gets them to come back. The loop is small:

• Grab coins while you hop, so every run has a second point beyond distance.
• Spend them to unlock characters, six of them, including a Pirate, a Ninja, and a Space Capy.

Cosmetic unlocks are a great fit for a casual game. They hand players goals without piling on rules to memorize, and “I just want the Space Capy” turns out to be a surprisingly sticky reason to keep playing. Everything is earnable by playing rather than paying, which keeps the game fair and builds goodwill instead of resentment.

Where vibe coding helped, and where it quit on me

AI assistance was great for the scaffolding: the core loop, procedural lane spawning, collision detection, the coin and save system, the unlock screens. It got me from nothing to a playable prototype fast, and fast is exactly what a fragile early game project needs, because the window where you abandon it is right at the start. Reaching “I can actually play this” quickly is what kept the whole thing alive.

What the AI could not do was tell me whether the game felt good. Tuning the hop, spacing hazards so they are hard but fair, pacing the difficulty so it pulls you forward instead of pushing you away, that is all taste and playtesting, and it stays human. An assistant hands you a working game. Only playing it, over and over, turns a working game into a fun one. That split between what the AI does and what you own is the same one I lean on everywhere.

What polish actually means

The biggest surprise was how much the invisible details mattered. A casual game lives or dies on a hundred things no player could name: the exact beat before the eagle appears, the weight of a landing, the half-second of feedback after a coin, the way the camera leans forward. None of it shows up in a feature list, and all of it separates a game that feels cheap from one that feels good in the hand. That attention to feel is a muscle. Build it on a game, where feel is the only thing you have, and you start spotting the same missing polish everywhere else, in the tools you were sure were already finished.

What shipping it taught me

• The first 30 seconds decide everything. Casual players judge fast. No fun first session, no second session. The opening has to land.
• Juice matters. The sounds, the little animations, the satisfying coin pop. That feedback is not decoration, it is the feel.
• Offline and free. No connection needed, progress saved locally, no paywall between the player and the fun. Friction is the enemy of casual.
• Constraints breed charm. One capybara and one clean mechanic beat the sprawling design I would never have finished. The limits made the game.

Building a game after a stack of tools was the best thing I did for my craft all year. It drags your attention onto feel, not just function, and that habit follows you home into everything else you make, including the serious apps where “it works” was quietly never quite enough, like my on-device AI chat app and private transcription app.

The itch

Three things kept bugging me about the mainstream AI apps I was using.

1. Privacy. Everything you type goes to a server, and often into training data.
2. Connectivity. On a plane or with one bar of signal, they are dead weight.
3. Cost. Another $10 to $20 a month for something I use in unpredictable bursts.

Meanwhile, on-device models had quietly gotten good. Good enough that I started to wonder what it would take to make all three complaints disappear at once. An AI that just lived on your phone, the way a calculator does, no strings attached. The idea nagged at me for weeks, so I gave in and built it.

The hard part: a language model on a phone

This is the point where the project stops being a UI exercise and turns into a systems problem. A phone is not a server, and its limits shape every decision you make.

• Memory. A phone might have 4 to 8GB of RAM, and it is sharing that with the operating system and every other app. A model that loads fine on a laptop gets killed on a phone without ceremony. The OOM killer does not negotiate. That constraint alone rules out most models before you start.
• Model size on disk. Nobody is going to sit through a 20GB download. Realistically you have a few hundred MB to a few GB to work with.
• Speed. Tokens per second has to feel like a conversation. If it prints like a fax machine, people close the app and never reopen it.
• Heat and battery. Push the processor flat out and the phone turns into a hand warmer and the battery evaporates. The work has to be efficient, not merely possible.

The thing that makes any of it work is small, quantized models. Quantization stores a model’s weights at lower precision, trading a little quality for a big drop in size and memory. I built around Qwen 3, from tiny 0.6B variants up to larger ones, plus GLM-Edge, including the vision-capable versions, with downloads landing somewhere between 500MB and 4GB. You pick a model that fits your device, download it once, and after that it runs offline.

There is a trade-off you have to make peace with, and be upfront with users about. A 1B model running on a phone is not a frontier model in the cloud. It will not write your dissertation. For quick questions, drafting, summarizing, brainstorming, rewriting, and anything at 30,000 feet, it earns its keep, and it is yours. Saying that plainly inside the app beats overpromising and losing someone on their first message.

Give users the dials, but hide them well

People want different behavior from a model, so I exposed the controls that matter: temperature, top-k, and top-p for shaping how loose or focused the output is, plus a “thinking” mode against a “fast” mode for when you want reasoning versus a quick reply. The danger with surfacing model internals is drowning a casual user in knobs they did not ask for. So the rule was simple: every control ships with a good default, and you can get a solid answer without ever opening the settings. Tinkerers get their sliders. Everyone else gets something that works out of the box.

Where vibe coding carried me

I am one person. There was no way to ship this typing every line myself. The AI assistant took the parts that are tedious but well understood:

• The chat UI: message bubbles, streaming tokens, scroll behavior, the copy button, the empty state.
• The model download manager: progress, resume after a dropped connection, storage checks, deletion to reclaim space.
• The settings layer: putting temperature, top-k, top-p, and the mode toggles somewhere a normal person can safely ignore.

What stayed on me was the hard 20 percent: wiring up on-device inference, managing memory so the app does not get killed halfway through a reply, and tuning the defaults so a non-technical person gets a good answer without touching a slider. The AI does the boilerplate, you own the load-bearing parts. That division between what the AI drafts and what I own by hand is the thing that makes the whole approach work.

Product decisions that mattered

• One download, then offline forever. The only friction is that first model download. After that, no network, no waiting.
• No account. An account is a privacy promise you can break. With none, there is nothing to leak, nothing to breach, nothing to log into.
• Defaults first, depth optional. Casual users get a model that answers. Power users get the sampling controls. Neither group pays for the other.
• Free. No servers means no costs to recover, which means no subscription, no billing, no churn to manage.

What I would tell another builder

On-device AI feels like magic to people because they assume it cannot be done. “You can run that on a phone?” That gap between what people expect and what you shipped is a wonderful place to stand, because the surprise does your marketing for you. Just respect the constraints. Match models to device tiers, be honest about what a small model can and cannot do, and spend your scarce hand-written hours on memory and performance, not on the parts an assistant can scaffold before lunch.

What I ended up with is an app I reach for myself, on planes, on the subway, any time I would rather not hand my private thoughts to a server. That is the bar I care about: would I use this if I had not made it. Privacy-first building turned into a whole theme after this one, and I followed the same thread into an offline speech-to-text app.