ReplyPixel — Pocket English Buddy Keyboard

ReplyPixel — a pocket English buddy that fixes your draft right from the keyboard, in any app.
Pip introduces itself and the whole pitch in one line — type it rough, send it fluent.
The ReplyPixel keyboard running live inside a plain notes app, not just inside ReplyPixel itself.
Pick your first language, and corrections start targeting the mistakes that language actually causes.
A streak, a mistake Pip caught, and recent fixes pulled straight from your own messages.
A real draft rewritten three ways — native, professional, and friendly — with zero typing needed.

Inspiration

I kept noticing the same pattern in friends who speak English as a second language: they'd write a text, delete it, rewrite it, delete it again, then send something shorter and safer than what they meant. Not because they didn't know the language, but because they weren't sure the sentence they'd written actually sounded natural, and there was nowhere to check without breaking out of the conversation. Grammar checkers exist, but they live in a browser tab, not in the keyboard where the sentence is actually being typed, and they read like a red-pen teacher instead of someone on your side. I wanted something that sat exactly where the writing happens, right in the keyboard, and treated a slightly awkward sentence as normal instead of a problem to be graded.

What it does

ReplyPixel is a keyboard replacement for iOS and Android built for non-native English speakers. You type your message as usual, tap a button, and get it rewritten in one of three tones: more natural, more formal, or more casual, without leaving whatever app you're in, whether that's iMessage, WhatsApp, Slack, or email. A companion character called Pip sits alongside the keyboard and reacts to what you write. It's built to feel like a buddy, so the product deliberately avoids words like coach, tutor, and grade. It also tracks the kinds of corrections you get most often and turns them into short, personalized lessons and a saved-phrases list, so the same mistake shows up less over time.

How we built it

The keyboard extensions are native: Swift on iOS, Kotlin on Android. A keyboard extension has almost no memory headroom (iOS caps them around 48 to 60MB) and no room for a heavy runtime. Android doesn't even give you a real text field inside a keyboard, so key input has to be committed directly to the host app through InputConnection, including handling backspace correctly across multi-character emoji. Rewrites go through a Cloudflare Workers gateway that calls Gemini, with Supabase behind it for auth (Apple, Google, and email sign-in) and for storing progress: streaks, fix counts, and the mistake patterns that drive the personalized lessons. Billing runs through RevenueCat. Everyone gets a set number of free rewrites, then a subscription unlocks unlimited use.

Challenges we ran into

The one that took the longest to settle was whether to run the rewriting model on-device instead of in the cloud, mainly for latency and privacy. Once we ran the actual numbers, it didn't hold up. The memory ceiling on iOS keyboard extensions rules out anything but a tiny model, and older or lower-end phones would produce a noticeably worse rewrite. We stayed cloud-based, and made sure Gemini runs on Google's paid tier specifically, because the free tier allows text to be used for model training, which isn't acceptable for something reading people's private messages. That created a second problem: an unlimited subscription on a per-token API is a real cost risk, so we added per-user rate limiting and usage tracking to close that gap before turning subscriptions on for real.

Accomplishments that we're proud of

Getting the rewrite loop to feel instant from inside a third-party keyboard, without it ever feeling like a grammar checker. And getting the personalization (patterns, lessons, saved phrases) to work without collecting anything that looks like a data grab: it's built entirely from fix history the user already generated, not new tracking.

What we learned

Sometimes the best outcome of a hard technical decision is the one you research seriously and then don't ship. The on-device model work wasn't wasted even though the answer was stay cloud. It forced real numbers into a decision that would otherwise have been made on vibes.