Mumbli – my personal Wispr Flow

Alex — Thu, 21 May 2026 13:37:54 +0000

My text-to-speech journey started roughly a year ago, when I tried it again and was impressed by how much faster it was than typing. I'd been fascinated by Churchill's use of a stenographer, and I knew it was a more efficient way to write things given proper editor post-processing. I'd tried dictation earlier, about 5 years ago, but it didn't work out - I tried using dictation and then sending it to people to transcribe, but it wasn't successful.

A year ago, I tried Whisper models with Python Qt, and it was fine. I used that initial Qt application for some time, but it was a bit ugly and not too easy to use. I found another application for Mac, and used it for a while.

After a year of using it almost every day, I've learned how to speak freely without hesitation. It's not perfect, but it's much faster, and I've been able to produce a lot more. A friend told me about Wispr Flow, which had a nice UI with a small overlay and simple key bindings. Although I didn't like the Electron application and the marketing, I picked the features I needed, like vocabulary, history of dictations, and key bindings.

That's how I created Mumbli, and so far, it's working well - I'm over 3300 transcriptions now. I can tweak it and try new things, like new GPT live transcription models.

The most useful part of owning the stack is that I can actually measure the pieces. Recently I benchmarked the latest 50 saved Mumbli recordings: 2,021 seconds of real dictation, with clips ranging from 0.3s to 293.8s. I ran the same recordings through a few STT providers and measured the time from "audio file is ready" to "transcript is back."

Provider	Model	Success	Median STT latency	p95 latency	Audio-judge wins
Groq Whisper	`whisper-large-v3-turbo`	50/50	534ms	1,098ms	2
ElevenLabs Scribe	`scribe_v1`	50/50	2,386ms	7,472ms	25
Interfaze STT	`interfaze-beta`	50/50	8,383ms	13,584ms	6
Tie / skipped	-	-	-	-	16 ties, 1 skipped

So the technical result is not "Groq wins everything." It is more specific: Groq was about 4.5x faster than ElevenLabs on median STT latency in this benchmark, and about 6.8x faster at p95. Compared to Interfaze it was much faster again. But ElevenLabs won the audio-judge comparison more often, so it still looks like the better quality default.

For my personal use, that split matters. Wispr Flow feels good partly because the interaction is tiny: hold a key, speak, release, get text. If the transcript comes back in half a second, the whole app feels different. It is the difference between "this is a transcription job running somewhere" and "this is close enough to typing latency that I keep using it."

So the setup is not one fixed answer. I can keep a quality-oriented path, and I can keep a fast path. That was the part I wanted from the Wispr Flow-like experience: the tiny overlay and simple hotkeys, but with the ability to swap the engine when the numbers say something interesting.

I've put the benchmark notes in the documentation: https://docs.mumbli.app/benchmarks#benchmarks-mumbli-performance. You can also check out the GitHub page: https://github.com/fireharp/mumbli, and the main site: https://mumbli.app/. No huge value here, just a nice tinkering approach - it was pretty fast to do, pretty exciting, and I still use it.

Simplifying Data for small teams and sole developers

Alex — Fri, 02 Jul 2021 22:11:13 +0000

Hello everyone,

I'm Alex co-founder of SimpleData https://datashouldbesimple.com/

TL;DR

Please help provide us some feedback on our early stage product )

Which part of our product you're interested in? (API, Reporting, other)
Which are languages you would use? (JS, Python, etc.)
Which are the platforms? (Backend, FE, iOS, Android, Desktop)

Any other free form feedback is highly appreciated.

I would also love to talk to any interested person personally (with my colleague John).

Short description

The high-level arch is pretty simple

⚙️ Consume data
🪄 Process it (not simple, haha)
🚀 Deliver prepared data, metrics in different ways: API, Reporting, custom apps

I'm thinking it should help a lot of developers and teams to simplify their experience with plethora of Data tasks and should make it easier, faster (or even possible when we talk scoring/models/pre-built metrics or some tools like reporting).

Simple Use case

Task Spec

This's a real scenario we used in one of our projects.

Let's assume you want to get all the info on some of your users and pass it over to colleague in Slack via Slack App command /user some@email.com

The information contains Billing, Activity (in your app), Communications and whatever else you have on this user. Including calculated metrics like LTV.

Implementation draft (w/o SimpleData)

If you start implementing this Slack App, you would need:

data from your DB (probably easiest)
data from 3rd party apps (Billing, all Comms – CS, maybe emails, Activity – events from user clients)

After some dev time – you got it.

Then you probably need to NLP analyse Comms for detecting sentiment (or use some app that does it for you). Calculate LTV. Evaluate churn risk, etc.

After more dev time – you probably also got it.

Overall time spent would be from week to a few weeks after all the debugging and business needs optimizations.

SimpleData implementation

from simpledata import User

# Get User Data
def get_users_data(email):
   user = User.objects.get(User.email=email)

   # basics
   age = user.age
   gender = user.gender
   # activity
   last_active = user.last_active
   activity_rank = user.activity_rank
   days_active_last7_days = user.activity(from_=datetime.now - timedelta(days=7), to_=datetime.now)
   # billing
   subscriptions = user.subscriptions
   transactions = user.transactions.tail()
   # etc.

Pretty short and simple. Even if you just start you developer journey. Or if you have several teams / lots of tasks — may simplify your hard work.

What about another usecases?

And we have them:

User Billing Info on your website
User Info Apps (like Slack App above – but may be elsewhere)
Reporting
Smart Alerts
Scoring Models
NLP Messages Processing (prioritization, sentiments, intent detection)
Socket + Client (serverless way – subscribe to our GraphQL API directly from client)

We're going to describe these and maybe more in our initial wiki and docs coming next few weeks.

Beta access to everyone from dev.to!

Expecting some initial invites-only beta access by end of summer ≈ (you are welcome sign up here! I'll prioritize all dev.to requests 😉)

DEV Community: Alex