Every founder who has looked at the writing-tools market has had the same idea we did, and most of them built a web app. A clean editor, a sidebar of suggestions, a share link. It is the obvious shape, it demos well, and it is straightforward to build.
We built a hotkey instead. Here is the reasoning, because it explains most of the product decisions that follow from it.
The tool you have to visit is the tool you forget
Writing at work does not happen in a writing app. It happens in Slack, in the Jira comment box, in the GitHub PR description, in the reply field of an email client, in a Notion doc someone else owns. Fifteen surfaces on an ordinary day, none of which is a text editor.
A web app asks you to leave all of those, paste your text somewhere else, fix it, and paste it back. That round trip costs perhaps twenty seconds. The problem is not the twenty seconds. The problem is that a tool with a twenty-second activation cost only gets used when you have already decided the text matters — which means it never touches the fifty short messages a day where the friction actually accumulates.
The messages that cost you the most are not the important ones you were going to edit carefully anyway. They are the quick ones you send slightly wrong, fifty times a day, because fixing them was not worth opening anything.
What “in place” changes
When the activation cost drops to a keypress, usage changes character. People stop deciding whether a message deserves editing and start editing everything. In our own team the median rewrite is nineteen words — a single Slack sentence, the kind nobody would ever paste into an editor.
That shift is the entire product. It is not a better model or a better prompt; it is removing the decision about whether to bother.
What we gave up
This is not a free choice, and it is worth being honest about the costs.
No cross-platform story. The mechanism depends on macOS Accessibility APIs and synthetic events. There is no shared core we can lift to Windows or Linux — a port is a rewrite. That is a real limit on the market, and the most common request we get.
No collaboration. There is no share link, no comment thread, no team library of approved phrasings. Some of that we will add. Most of it belongs in a document tool, not a hotkey.
Harder distribution. A web app is a URL. We are a signed, notarised binary that has to ask for Accessibility permission on first launch, which is exactly the permission dialog that has taught Mac users to be suspicious. We lose people at that dialog. The fix is not a better dialog; it is being the kind of company whose explanation of why it needs the permission is believable.
Harder support. Every app implements text selection slightly differently. A web app has one text area we control. We have Slack, Electron, Chrome, Xcode, Figma and a long tail, each with its own failure mode.
Why it was still right
Because the alternative was building a good version of a thing people do not open.
We tested this before committing. An early build was a menu-bar window: paste in, get a rewrite, copy out. Faster than a web app, no context switch to a browser. People used it for a week and stopped — not because the output was bad, but because pasting is still a decision, and most messages do not clear that bar.
The hotkey version had the opposite problem. People used it constantly and complained about latency, model choice, and prompt configuration. Those are complaints about a tool that is in the way of real work, which is the only kind of complaint worth having.
What follows from it
Nearly every roadmap decision falls out of this one. Latency matters more than capability, because a hotkey that takes two seconds stops being a hotkey. Configuration must be local, because there is no server-side session to hold it. Undo must use the host app’s own undo stack, because that is the one you will actually press. And no feature is allowed to add a window.
If a feature requires you to look at Promptshot, we have probably got it wrong.