The Push: July 24th, 2026
Private grammar AI, self-hosted static sites, and a terminal copilot that actually knows how to delegate
Harper: Grammarly’s Weakest Assumption
github.com/Automattic/harper | License: Apache-2.0
Writing a doc in Google Docs, cleaning up notes in Obsidian, or fixing a README should not trigger a silent upload of every sentence to somebody else’s servers. Yet that is still the default for grammar software. Harper lands on a simple claim: grammar checking should be fast, local, and less annoying. That sounds obvious until the alternatives force a tradeoff between privacy, speed, and decent suggestions. Honestly, the surprising part is not that this exists. It is that mainstream writing tools still assume the cloud belongs in every keystroke.
The Drop: Privacy Should Not Add Friction
Grammarly trained people to accept a weird bargain: hand over drafts, emails, journal entries, meeting notes, and half-finished thoughts in exchange for a cleaner sentence. That bargain gets shakier once AI features enter the picture, because “writing assistance” starts to blur into “training corpus.” On the other side, open alternatives have often felt like research projects, heavy installs, huge memory use, slow feedback, and corrections that arrive late enough to break the flow.
Harper exists because that experience is off. Grammar help only feels useful when it is immediate and trustworthy. A tool that pauses for seconds, phones home, or floods the page with nitpicks becomes background irritation, not augmentation. The repo’s README is unusually blunt about this frustration, and that bluntness matters. Harper is not chasing maximal linguistic ambition. It is trying to be the checker that is “just right,” meaning quick enough to stay invisible, private enough to feel safe, and restrained enough that users do not end up fighting the product.
The Stack: Rust With Browser Reach
Under the hood, Harper is built primarily in Rust, which makes sense for a text engine that cares deeply about latency and memory footprint. Around that core sits a spread of integrations, including WebAssembly for the browser, plus JavaScript and TypeScript layers for extensions and editor plugins, with React and Svelte appearing in the surrounding product surfaces.
The Sauce: A Grammar Engine Built Like Infrastructure
Latency is the architectural story here. Harper is not interesting because it checks grammar, plenty of products do that. Harper is interesting because the checker is designed as a compact local engine that can run across editors, browsers, and note apps without turning every sentence into a network event.
Several pieces make that work. First, the core engine lives in Rust, which keeps performance predictable and the memory footprint small enough for constant background use. Second, Harper ships through WebAssembly, which means the same core logic can run inside web contexts, not just native apps. That matters because it turns grammar checking into portable infrastructure, not a single app feature. Third, the project has a language server integration path, which is a clever distribution choice. Instead of rebuilding the whole experience for every editor, Harper can plug into environments that already know how to consume diagnostics, suggestions, and inline feedback.
Another underappreciated choice is format awareness. The repo includes parser support for things like comments and markup-heavy documents, which means Harper is not merely scanning raw text blobs. It is identifying the text humans actually mean to edit, while avoiding the structural noise around it. That sounds small, but it is the difference between a useful writing layer and a pedantic mess. The net effect is a checker that behaves less like SaaS and more like a local compiler pass for prose, quiet, fast, and reusable anywhere text shows up.
The Move: Turn Writing Quality Into Default Behavior
Teams can put Harper to work in a few high-value places immediately. Product orgs can add it to internal docs, specs, support macros, and release notes, where tone and clarity matter but nobody wants sensitive drafts sent to a third party. Founders can drop it into note-taking and browser workflows, e.g. Obsidian or Chrome, and get always-on editing help without the subscription overhead or data anxiety. Engineering teams get a bonus angle: because Harper supports editor and language-server style integrations, documentation quality can start living closer to the places where writing already happens.
That creates a strategic edge beyond cleaner copy. Local grammar tooling reduces review churn on async docs, shortens the time between draft and publish, and makes privacy-sensitive writing easier to standardize across an org. There is also a product opportunity here for anyone building text-heavy software. Harper can become the embedded writing layer inside knowledge tools, customer support systems, CRMs, and internal platforms. In other words, the advantage is not “better grammar.” The advantage is owning a fast, private text-quality primitive instead of renting one.
The Aura: People Write Differently When They Trust the Tool
Writers hesitate when software feels nosy. Drafts get shorter, rougher thoughts stay unwritten, and private notes stop being truly private. Harper changes that emotional contract by making assistance feel local, immediate, and contained. That is bigger than grammar.
Software like this nudges a new expectation into place: intelligence can live on-device and still feel polished. Once that expectation sticks, cloud-first defaults start looking less premium and more intrusive. The behavior change is subtle but important. People become more willing to think in text when the machine helping them is not also watching.
The Play: A Privacy-Native Writing Layer
From a VC lens, Harper looks less like a 0-to-1 new category and more like a sharp wedge into a very large existing TAM: writing assistance, workplace productivity, and embedded text tooling. The upside comes from distribution and developer adoption, not just consumer subscriptions. A fast-growing open source repo with 12,865 stars, multiple plugins, and clear cross-surface demand is a real PMF signal, especially when the product sits inside daily workflows where LTV can get strong and CAC can stay low through community channels.
The moat is not raw model IP. It is execution speed, portability, and trust. If Harper becomes the default embedded checker across editors, browsers, and note apps, switching costs rise through workflow habit and integration depth.
Winners:
Readwise: Better offline writing assistance inside Reader and note workflows compounds engagement because users can clean and publish thoughts without leaving the product or exporting text to a third party.
Notion: Stronger private-by-default editing across enterprise workspaces improves retention in regulated teams where every external SaaS integration increases procurement friction.
Automattic: Broader ownership of the writing stack, from WordPress to browser and editor surfaces, deepens ecosystem control around text creation where distribution is already massive.
Losers:
Paragraph: More capable embedded grammar and editing layers inside other products erode differentiation for a younger publishing tool that still needs every workflow advantage.
Grammarly: Premium pricing and cloud dependency get harder to defend when “good enough plus private plus instant” keeps improving in open source.
Google: Server-centric writing assistance looks less inevitable as local-first expectations spread across docs, notes, and browser-based text entry.
tl;dr
Harper turns grammar checking into a fast, offline, privacy-first layer that can live across browsers, editors, and note apps. The clever part is the Rust core plus WebAssembly and language-server distribution, which makes the engine portable instead of app-specific. Anyone building or buying text-heavy software should look.
Stars: 12,865 | Language: Rust
