We started building Linguix in mid-2025 with a clear conviction and a less-clear product plan. The conviction: most writing tools were built for native English speakers, and the patterns that actually trip up professional non-native writers were under-addressed. The product plan: we would build a browser extension that catches those patterns inline, without requiring users to change their workflow.
Here is what the first six months actually looked like.
What we got right early
The decision to build inline from the start was right. We considered a simpler first version that would have been a sidebar or a paste-and-check flow, mostly because inline was technically harder. But every conversation we had with potential users in the early months came back to the same point: they did not want another tab or another window. The value was being corrected in the place where they were already writing. We kept the technically harder path and it was the right call.
The other good early decision was focusing specifically on professional email as the primary use case. We could have built a general writing tool. Instead we trained on email, optimized for email contexts, and built the product with Gmail and Google Docs as the first-class platforms. This specificity made every subsequent decision easier, from dataset selection to default behavior to how we frame suggestions to users.
What we got wrong early
We underestimated how much of the product was the explanation, not the correction.
In the first version, suggestions appeared with a one-line correction. "Replace with: [alternative phrase]." That was it. No explanation, no context, no indication of why the original phrasing was being flagged. Users accepted some suggestions and ignored others, and the acceptance patterns told us almost nothing about whether they understood what they were accepting.
Then we added explanations. Brief ones: a sentence describing the grammar or style issue and why the suggested alternative addressed it. The response was immediate and significant. Not just higher acceptance rates, but better feedback from users about which suggestions felt useful versus arbitrary. The explanation is what separates a tool that helps writers improve from a tool that just autocorrects their text. We built the correction first because it was the obvious thing to build. We should have built the explanation layer at the same time.
The non-native speaker assumptions that did not hold
We assumed that non-native English speakers in professional roles were primarily struggling with grammar. Subject-verb agreement, article usage, preposition errors. These are the patterns that language textbooks emphasize and that standardized tests measure.
When we started getting usage data from early users, the picture was more complicated. Grammar errors were present and our detection was catching them. But the feedback that came back most consistently was about something different: users wanted help with register. They were writing correctly and being perceived as overly formal, stiff, or indirect in contexts where their colleagues expected more conversational English. "I have received your message and am now in the process of addressing the items contained therein" versus "Got your message, working through the items now." Both are correct. One sounds like a form letter from 1985.
This was genuinely useful signal. It shifted how we prioritized the style layer and what we focused on in the user interface. But it also meant that a significant portion of our early feature prioritization had been based on an incomplete model of the actual user problem.
The feedback that changed how we think
About three months in, we got feedback from a user who described their situation clearly enough that it reframed how we thought about the product.
They were a software engineer from Ukraine, working at a company in the US. Their English grammar was strong. They had been writing in English professionally for several years. The issue they described was not about being corrected on grammar. It was about the gap between knowing English rules and knowing how English-speaking professionals actually communicate at work. Idioms. Register. The difference between sounding capable and sounding like you are translating in your head.
This is not a grammar problem. It is a fluency problem of a different kind, and it is genuinely harder to address with automated tools. We cannot fully solve it. But the feedback clarified that the population we were trying to help was not "people who make grammar mistakes." It was "people who write correctly but want to sound more like they belong in the professional context they are in." That is a different product problem and a harder one.
Numbers from the first cohort
We ran a structured early-access program with around 40 participants over the first three months. These are the patterns we tracked.
Grammar corrections: the average user accepted roughly 60% of grammar suggestions. The acceptance rate was higher for preposition errors than for article errors, which aligns with what we expected: article correction in English is genuinely ambiguous in ways that make some of our suggestions feel wrong even when they are technically correct.
Style suggestions: acceptance was lower, around 40%, which also aligned with expectations. Style suggestions are more context-dependent, and users rightly rejected some of them for reasons they understood better than we did.
Retention: users who came back after the first week used the extension consistently. Users who did not return after the first week had almost universally encountered the extension interrupting their writing in a context where it was not helpful. This was the most important usage pattern we saw: the first negative experience determined whether users returned. Getting the first session right became a product priority.
What six months taught us about building in this space
The writing assistance space has a deceptively simple surface and a genuinely complicated interior. "Catch mistakes and suggest fixes" sounds straightforward until you get into what counts as a mistake, what constitutes a fix, and what happens when a correction that is technically right is contextually wrong.
The constraint we have found most valuable is specificity. Building for non-native professional writers in email contexts, rather than for all writers in all contexts, has meant that almost every product decision has had a clear frame for evaluation: does this help this person write email that sounds the way they intend? That question is tractable in a way that "is this good writing assistance?" is not.
We still have a long way to go. But the direction is clear.