Building for the Other 80%: AI Writing Tools for the World That Isn't Native
The majority of English used at work today is written by people for whom English is not a first language. Remote teams are stitched together across São Paulo, Bangalore, Warsaw, and Manila, and the shared language of the standup, the pull request, and the customer email is English — a second language for most of the people typing it.
And yet almost every writing tool is built as though the user grew up speaking it. That gap is the reason we built PhraseKit, and it changes far more about the design than you’d expect.
A grammar checker isn’t a translator, and neither is enough
The mainstream tools are good at one thing: catching mistakes a native speaker might make. A missing comma, a passive-voice nudge, a repeated word. Useful, but it assumes the writer already sounds native and just slipped.
The second-language writer has a different problem. Their errors are systematic, and they come from their first language. A Spanish speaker reaches for “actually” when they mean “currently,” because actualmente pulls them there. A Japanese speaker drops articles because their first language doesn’t have them. A German speaker writes a sentence that is grammatically flawless and unmistakably German in its rhythm. None of these are careless slips. They’re the fingerprint of the writer’s native language pressing through.
A tool that only knows English can flag the symptom. It can’t see the cause.
First-language awareness
So PhraseKit is built to know where you’re coming from — literally. It supports 17 native languages, versus the five that a tool like Grammarly covers, and it uses that knowledge to give corrections that target the mistakes a speaker of your language actually makes.
The payoff isn’t only better fixes. It’s better understanding. Every suggestion comes with a short explanation of why it changed — and that explanation can be shown in your own language. For a lot of our users that’s the first time a writing tool has taught them the underlying rule instead of silently rewriting them. The correction fixes today’s sentence; the explanation fixes the next hundred.
Design decisions that fall out of this
Once you take the second-language user seriously, a cascade of choices follows:
- It has to be everywhere. These users don’t live in one editor. They write in Slack, Gmail, Jira, a terminal, a doc. So PhraseKit is a system-wide desktop tool behind a hotkey, not a browser extension bolted to one site.
- It has to be on Windows. A striking number of writing tools for non-native speakers are Mac only — which quietly excludes a huge share of the exact people who need them most. Cross-platform isn’t a nice-to-have here; it’s the whole point.
- It has to respect the hardware. Our users run whatever machine their job provided. A tool that demands a top-tier laptop isn’t inclusive — a lesson we learned the hard way with local models.
- It has to earn trust. People are careful about handing their unpolished writing to a service. So privacy is built in, not promised later.
The bigger point
There’s an enormous, underserved population sitting in the overlap between “works in English all day” and “didn’t grow up speaking it.” Building for them isn’t charity and it isn’t a niche — it’s most of the professional world. The tools just haven’t caught up.
That overlap is where we like to build. If you’re working on a product for a global audience and the defaults keep assuming an American user, we should talk.