I thought Citrix support was an edge case. It turned out to be the wedge.

I thought I was building a better dictation app. Then Citrix users showed me the real problem.

When I started building DictaFlow, I thought I was competing on the usual stuff: accuracy, speed, price, maybe a nicer UX. That was the obvious indie founder view of the market.

Then the first weird customer emails started showing up.

A doctor wanted dictation inside Epic through Citrix. A lawyer wanted it in a remote desktop where paste was blocked. Someone in finance said every voice tool they tried worked in Notes and Slack, then died the second they opened the actual app they got paid to use.

That was the moment I realized a lot of software founders, myself included, accidentally build for the demo environment. Clean machine. Local app. No IT policy. No remote session. No ancient enterprise software running inside three layers of lockdown.

The real world is messier than that.

What these users taught me is that the product problem wasn't "make dictation better." It was "make dictation survive the places where normal software breaks."

A few lessons came out of that.

First, the bottleneck usually isn't the core feature. It's the environment around the feature. A lot of dictation tools can turn speech into decent text now. That part is getting commoditized fast. The failure happens one step later. Can the text get into the field the user actually needs? Can it work in Citrix, VMware Horizon, RDP, browser-based EMRs, weird Java apps, or locked-down Windows desktops where clipboard behavior is flaky or blocked outright? Founders love improving the clever part. Users care about whether the dumb final mile works.

Second, enterprise friction shows up as product friction. Users don't say, "my organization has a restrictive endpoint policy that prevents standard insertion methods." They say, "your app doesn't work." And honestly, they're right. They don't care why it fails. They just know the tool works in a notes app and fails in the one place that matters. I think a lot of founders miss this because the bug is technically outside the app, but commercially it still belongs to the app.

Third, boring implementation details can become the whole wedge. One of the biggest aha moments for me was realizing that typing text through keystroke simulation mattered more than adding another flashy AI layer. It sounds painfully unsexy. But it's also the difference between "nice demo" and "I can use this all day at work." The more I talked to doctors, lawyers, and people in locked-down corporate setups, the less they cared about magic and the more they cared about reliability.

Fourth, niche use cases are often better than broad categories. "AI dictation" is crowded and mushy. "Types into Epic through Citrix" is narrow, a little ugly and immediately understandable to the right buyer. Same with VDI, remote desktops, and clipboard hostile apps. Those use cases aren't glamorous, but the pain is sharp and the competition is a lot weaker.

The bigger lesson for me as a founder is that product differentiation sometimes hides inside constraints. If you only watch what works in ideal conditions, you end up shipping the same app as everyone else, just with slightly different branding. But if you pay attention to where users swear, retry, give up, or email support with oddly specific complaints, the roadmap gets a lot clearer.

I still sell DictaFlow as a general dictation product, and I should, because plenty of people just want hold-to-talk dictation that works across Mac, Windows, and iPhone. But the locked-down environment story changed how I think about product work. The edge case wasn't really an edge case. It was the map to a real market.

I'm curious how other founders think about this. Have you found that your best wedge came from some weird constraint or annoying environment that bigger competitors mostly ignored?