Decision 1: no account, at all

The easiest way to make a tool feel "serious" is to put a signup wall in front of it. It also kills a huge fraction of people who just wanted to check if the tool works before trusting it with a real file. I went the other way: open the page, drop a file, get a transcript. No account, no email, nothing to remember a password for.

The cost: I can't build a user profile, can't email people about new features, and every session starts from zero context. I accepted that tradeoff on purpose. The daily/total usage limits (4 hours a day, 10 hours total, resetting at 00:00 UTC) exist specifically because there's no account layer to rate-limit against — anonymous usage needs a hard ceiling instead of a per-user quota.

Decision 2: a real deletion timer, not a policy sentence

A lot of "we care about your privacy" pages just say a variation of "we take privacy seriously" without committing to anything checkable. MP3toText deletes the uploaded audio and the resulting transcript 24 hours after upload, full stop. That's a hard operational constraint, not a marketing line — it means nobody can go dig up a file from a month ago even if they wanted to, including me.

The cost is on the user's side: if you don't export what you need within a day, it's gone. For a one-off interview or meeting that's fine; for someone trying to use it as a permanent archive, it's the wrong tool, and I say so.

Decision 3: publish the accuracy ceiling, not just the headline number

The honest number is "around 99% word accuracy on clear speech," and then it degrades with accents, background noise, and overlapping speakers — the same failure modes every speech-to-text system has. I'd rather a user find that out from the FAQ before they upload a noisy phone recording of a three-person meeting than discover it by being disappointed with the output.

This matters more for a no-signup tool than a subscription one: there's no account manager or support relationship to smooth over a bad first impression. The product copy is the only chance to set expectations correctly.

Decision 4: export formats follow the reader, not the writer

Plain TXT covers "I want to read this and search it." SRT and VTT cover "I want this as subtitles." Both carry the same speaker labels and per-line timestamps if you want them — timestamps are what make a transcript actually navigable instead of a wall of text you still have to skim.

The format choice sounds trivial until you watch two different users want completely different output from the same recording: a podcaster wants subtitle files, a researcher wants clean plain text to paste into an analysis tool. Supporting both from one transcript is cheaper than it looks; supporting only one is a silent way to lose half your users.

What I'd still change

• No API and no browser extension yet. Anyone doing this at any volume wants one or both, and right now the only door in is the web page.
• The file-size and duration ceiling (2GB / 4 hours) is generous for most calls and lectures but genuinely blocks a full-day conference recording.
• There's no published paid tier. The free allowance covers casual use, but I haven't decided — or announced — what happens for people who consistently need more than that, and I'd rather say nothing than promise something that isn't built yet.

None of this is a "we're perfect" post. It's closer to a running list of the tradeoffs I made on purpose, and the ones I'm still sitting on. If you're building something with a similar no-account, single-purpose shape, the account-wall tradeoff and the deletion-window tradeoff are the two I'd think hardest about before copying anyone else's defaults.