Why local-first is a product decision, not only an architecture choice
Building MemoFlow means thinking about the awkward first recording, the words a model gets wrong, and what happens when someone wants their notes back.
I don’t want to edit myself before I start dictating. If I’m trying to write a difficult email, I want to try a sentence, hear how it sounds, and change my mind. The person receiving it needs the finished email. They don’t need every version I went through to get there.
That’s the sort of material MemoFlow handles. I build it for meeting notes and dictation on the Mac, with support for English, Hindi, and Hinglish. [1] A transcript might contain a suggestion someone immediately withdrew, or a number everyone understood was provisional. It needs more care than a document someone has already decided to share.
Keeping that work on the person’s machine makes sense to me. But choosing where to run a model also leaves you with decisions about the rest of the app. Someone still has to install it, understand what it’s doing, and trust it enough to use it during an actual conversation.
Be specific about what leaves the Mac
MemoFlow records and transcribes locally by default. It also lets you enable Gemini or OpenRouter with your own API key for selected AI tasks. In that case, transcript text goes to the provider, and its policies apply. The audio stays on the Mac. [2]
I think that choice is reasonable. Someone may want a cloud model for a particular task, and the setting should tell them which text would leave their machine before they turn it on. I wouldn’t want to piece that answer together from a landing page and a privacy policy while a conversation is about to start.
People notice the wait
When you finish dictating, you’re usually ready to carry on. If nothing appears, you hesitate. Did it hear you? Should you repeat the sentence? At some point, typing starts to look easier.
MemoFlow inserts dictated text into the app you’re already using, and local transcription works offline after the models have downloaded. [1] There’s no network round trip in that path. There is still processing to do on the Mac, though, and that wait counts just as much to the person sitting in front of it.
I care about whether someone can tell recording has started and stopped. A fast model doesn’t help much if the interface leaves you wondering whether it ran at all. And a result from a quiet test machine tells you only so much about how an app will feel alongside a meeting and everything else someone has open.
Before any of that, there’s setup
The person installing MemoFlow may just want to record their next meeting. First, they need to download a model and grant the app permission to hear audio. Dictation also needs permission to insert text into another app. That’s quite a lot of setup for something they haven’t tried yet.
In version 0.6.0, permissions are on one screen. Model setup shows download and preparation progress, and people practise the shortcuts during onboarding. Version 0.5.0 also added microphone fallback and tones when recording starts or stops.[3]
A download with no visible progress makes it hard to know whether to wait or restart. A disconnected headset shouldn’t cost someone the rest of a meeting. If either happens, explaining that the AI runs locally won’t make the experience any less frustrating.
Hinglish changes how I’d judge a model
Take a sentence like “Kal client ko updated proposal bhejna hai.” It means the client needs the updated proposal tomorrow. The English words belong in that Hindi sentence. You shouldn’t have to translate the thought into one language before saying it out loud.
MemoFlow handles Hindi and Hinglish locally, and uses different default engine choices for English and for Hindi/Hinglish. [1] [3] I’d be reluctant to call an engine better just because it finishes sooner. If you have to repair the words that carried your meaning, some of that time saving has already gone. A useful test needs speech like the sentence above, with the language switches left in.
The Mac has to do the work
MemoFlow currently needs Apple Silicon and macOS 26. Local summaries and chat use Apple Intelligence.[1] That rules out some machines before anyone gets to try it. For the people who can use it, memory and battery use still matter, as does the space needed for model downloads.
Storing the files locally brings another responsibility. MemoFlow relies on the Mac’s account protection and FileVault, if enabled; it doesn’t add its own encryption layer.[2] Local files can still be lost, and keeping them on your laptop doesn’t give you a backup.
I’m comfortable with these trade-offs, provided they’re explained before someone starts relying on the app. “On my Mac” can sound more reassuring than it should if you haven’t thought about what happens to the files.
Make it possible to leave with your notes
A note you recorded months ago can become useful again, even if you’ve stopped using the app that created it. I want people to retain access to that work. The Ink & Switch essay includes this long-term control in its local-first principles, alongside offline use and collaboration. [4]
MemoFlow’s 0.6.0 release notes say that recordings remain readable and exportable after the trial. A licence is needed for new recording and AI features, and the app checks it on launch and daily. [3] Running the models locally doesn’t mean the app has no network dependency for licensing.
I want someone to be able to speak a rough thought and get on with their day. Later, they should be able to find a decision or check what was said. And if they decide to use something else, they should be able to take those notes with them. I wouldn’t want to pay for an app again just to read a note I’d already made.