All Projects

SuperSpell

Try It

SuperSpell is an AI powered spelling assistant that I designed and built end to end, from identifying the user problem to shipping production ready integrations in Word, Obsidian and the browser. This project shows how I approach AI innovation and custom tooling: start from a real workflow, prototype quickly, connect multiple systems, and iterate based on usage and feedback.

The Problem:

For those who make a lot of spelling mistakes, whether it be because of careless typing, non-native writing, or a learning disability, the existing options for spelling correction were not enough. The existing workflow by which the text editor detects spelling mistakes and indicates this to the user by means of a red squiggly is helpful but, for those who make a lot of mistakes the constant re-reading and manual correction of misspelled words is time-consuming, breaks the writing flow, and is unhelpful.

The Concept:

SuperSpell's novel approach is to remove the manual overhead of correcting obvious spelling mistakes but automatically detecting and correcting mistakes. Instead of asking the user to stop and manually correct each word, they can now focus on typing and be confident that their text is being captured and reprocessed without spelling mistakes. This breaks the distinction between "writing" and "proofreading" allowing for a new AI powered writing workflow.

How it Works:

  1. Detection and trigger: The add in detects when a paragraph is finished

  2. Request to backend: Text and user data is sent to a Node.js backend over an API.

  3. Backend Logic: The request is authenticated with Firebase. User plan and daily limit are enforced. Usage is logged to MySQL.

  4. LLM: Once all backend tests pass, the LLM is called with a custom optimized prompt.

  5. Post Processing: The LLM output is received and processed to create a Diff comparing the original user input with the LLM output. This Diff information is then encoded and packaged into the relevant markup for each frontend. For example, Word expects tracked changes to be in OOXML format. Obsidian runs on CodeMirror.

  6. Client Insertion: The client receives the response from the backend with the corrected text and modified Diff encoding to replace the misspelled text with corrected text and visualizing to the user what has changed.

Design Guidelines:

Building Process:

I started with a simple browser based prototype to validate the core loop: type a paragraph, send it to the backend, get back corrected text with diffs, and render the changes. This let me iterate quickly on prompt design and edge cases. I wanted to balance the amount of text I send, since a larger context helps with harder to parse misspellings, but also increases token usage. I tested different granularities for correction, from word and sentence level to paragraph and document level. Through testing and evaluation I found that paragraphs offered the best trade off between token usage and the amount of spelling corrections captured.

The easiest first step was to put all the pieces together in a simple HTML page on localhost to quickly get a visual representation and enable local editing, creating a fast prototyping loop.

This initial proof of concept took user input and ran it through the Node.js backend and processing pipeline to produce the corrected output.

SuperSpell Demo

Creating these fast prototypes was key to validating the initial architecture and structure, and allowed for short iteration cycles.

Tech stack:

Backend and AI layer

Clients and integrations

Product, automation and analytics

Further Work:

While working on this project I realised that the space of real time user interaction is still underexplored. Many tools wait for the user to finish an action before doing any meaningful work. Text boxes sit idle until we press Enter. Buttons do nothing until they are clicked. But in many cases, more computation could happen quietly in the background while we work. SuperSpell is one example of this idea: instead of waiting for users to manually fix mistakes, it continuously cleans up the text as they write.

The same thinking applies to the ubiquitous LLM prompt box. Today it is usually a static input that only does anything after we hit Send. But there is much more we could do with that surface. An LLM could read the emerging input in real time and, before Enter is pressed, suggest refinements, highlight ambiguities, or offer alternative directions for the query.

We already see early versions of this in code completion tools and search autocomplete, but that is only a starting point. There is a large space of interaction design available in the moments before a user commits an action. I see this “input surface” as a promising area for future work on how we interact with software and how AI can support users without getting in their way.