u/IKiThomas

Murmure by Cyberesia launched today. It's a native macOS app (Apple Silicon only) that records, transcribes, and turns audio into structured documents. Everything runs locally, no cloud involved.

I want to share the pricing decision because it's unusual and I've been asked about it already.

Why one-time instead of subscription:

We're targeting lawyers, therapists, consultants, and executives, people with a legitimate professional reason to never put client audio in a US cloud. For that buyer, a subscription means a recurring vendor relationship they have to justify to compliance. A one-time purchase is a tool they bought, like any piece of software. Psychologically and practically, it's cleaner.

189 CHF (yes i'm Swiss) gets you the app and 2 years of updates. After that, the app keeps working. You can opt in for further updates later if we ship things you want. We're not holding the software hostage.

After the Preview window, new buyers pay 289 CHF/year subscription for updates. The one-time cohort keeps their license.

What the product does:

Three areas: Murmure (capture + live chat + system-wide dictation in any macOS app), Studio (long-form audio to structured doc with presets), History (everything indexed and searchable). The pipeline runs on-device: Whisper-large for transcription (with speaker diarization on the heavier path), MLX community models for generation, local vector search for retrieval. Ollama-compatible if you already have it running. Optional MLX privacy filter (~1.5GB) that scans transcripts locally for sensitive data. Exports to Markdown, PDF, Word. Nothing hits a server.

One thing worth saying clearly:

We run open source models: Whisper, MLX community models, Ollama-compatible. The value isn't proprietary AI; it's the pipeline, the UX, and the macOS integration (system audio capture, sandboxing, onboarding, presets, export).

What's still rough:

• Language paths are FR + EN optimized on the heavier Whisper path. Other languages use the same model weights and work, but we haven't tuned prompts or stress-tested outside those two.
• Setup takes 5-10 minutes the first time (model downloads ~4.6GB for the default LLM, ~1.5GB optionally for the privacy filter).
• No Windows, no Linux. Apple Silicon is the prerequisite.

Would love brutal feedback from anyone who's shipped something similar or has thoughts on the one-time vs. subscription trade-off for B2B tools.

Landing page if u want to roast me: https://www.cyberesia.com/products/murmure

Most of the advice I read said: launch consumer first, prove the product, then go upmarket. We did it backwards by accident, and I think it was the right call.

Before we had a landing page, a pricing tier, or even a name for the consumer version, a public sector organization reached out. They had a data sovereignty requirement that nobody in the market was meeting. They needed AI infrastructure that stayed on-premise, with no cloud dependency whatsoever. Not "we promise not to store your data." Architecturally impossible to exfiltrate.

We said yes. We spent weeks inside that procurement process.

Here's what that experience gave us that no amount of beta testing would have:

1. The hardest buyers surface the requirements that turn out to be universal.

Public sector procurement is brutal. Every edge case gets filed as a requirement. Audit trails, offline operation, model transparency, data residency. We built all of it because we had to. When we later talked to lawyers, therapists, and consultants about the consumer version, they wanted exactly the same things. We already had them.

2. Enterprise revenue bought us the time to build the consumer product properly.

We didn't rush the consumer launch. We had runway. That meant we could sit with the product until the onboarding didn't need a manual, until the hard workflows actually worked on modest hardware, until the presets felt like real professional tools and not demo features. You can't do that on zero revenue.

3. The reference changes the consumer conversation.

When a prospective buyer asks "but is this actually private?" and your honest answer includes "it's the same architecture deployed for clients with legal data sovereignty obligations," the conversation changes. You're not making a promise. You're pointing at a proof.

The thing I'd push back on in the standard "consumer first" advice: it assumes your product is one where consumer feedback maps cleanly to enterprise requirements. For us it didn't. Our enterprise buyers were more demanding and more specific than our consumer buyers, and everything they forced us to build made the consumer product better.

If your product has any overlap with regulated industries or compliance-heavy buyers, I'd genuinely consider whether going enterprise first, even on a single deal, might be the smarter sequencing.

Curious if anyone else has done it this way or has thoughts on why the B2B SaaS-first orthodoxy is so dominant.

Most of the advice I read said: launch consumer first, prove the product, then go upmarket. We did it backwards by accident, and I think it was the right call.

Before we had a landing page, a pricing tier, or even a name for the consumer version, a public sector organization reached out. They had a data sovereignty requirement that nobody in the market was meeting. They needed AI infrastructure that stayed on-premise, with no cloud dependency whatsoever. Not "we promise not to store your data." Architecturally impossible to exfiltrate.

We said yes. We spent weeks inside that procurement process.

Here's what that experience gave us that no amount of beta testing would have:

1. The hardest buyers surface the requirements that turn out to be universal.

Public sector procurement is brutal. Every edge case gets filed as a requirement. Audit trails, offline operation, model transparency, data residency. We built all of it because we had to. When we later talked to lawyers, therapists, and consultants about the consumer version, they wanted exactly the same things. We already had them.

2. Enterprise revenue bought us the time to build the consumer product properly.

We didn't rush the consumer launch. We had runway. That meant we could sit with the product until the onboarding didn't need a manual, until the hard workflows actually worked on modest hardware, until the presets felt like real professional tools and not demo features. You can't do that on zero revenue.

3. The reference changes the consumer conversation.

When a prospective buyer asks "but is this actually private?" and your honest answer includes "it's the same architecture deployed for clients with legal data sovereignty obligations," the conversation changes. You're not making a promise. You're pointing at a proof.

The thing I'd push back on in the standard "consumer first" advice: it assumes your product is one where consumer feedback maps cleanly to enterprise requirements. For us it didn't. Our enterprise buyers were more demanding and more specific than our consumer buyers, and everything they forced us to build made the consumer product better.

If your product has any overlap with regulated industries or compliance-heavy buyers, I'd genuinely consider whether going enterprise first, even on a single deal, might be the smarter sequencing.

Curious if anyone else has done it this way or has thoughts on why the B2B consumer-first orthodoxy is so dominant.