What I learned building Keygram
Keygram is an iOS keyboard for typing Indian languages the way people actually type them: romanized, code-mixed, and spelled however you like. It's live on the App Store. I built it over most of 2026.
As of now, it's going into maintenance mode. It'll stay on the App Store, I'll fix what breaks, but no new features.
This is the honest version of why. What worked, what didn't, and what I learned about the gap between building something good and building something people pay for.
What worked
- The core insight was right. Mainstream keyboards really do misfire on romanized code-mixed text, and "your spelling is not a typo" is still how I'd build it.
- Small models, built from scratch, on almost no money. A 13.44M parameter language model, a swipe model at 89% top-1 on our English test set (FUTO reports 85.6% on theirs; different test sets, so not a head-to-head), and a 78% Hindi swipe result on synthetic traces. All on a Modal budget of tens of dollars.
- Gates before decisions. Setting a number before every experiment saved me from shipping ideas that felt right and weren't. The canonical-class idea died this way, twice.
- Fixing the pipeline before adding features. The 114ms latency bug and a memory check that silently switched off the neural model were the most valuable fixes in the whole project. Neither was a new feature.
- Privacy built into the structure. Keyboard text stays on the phone, typing rhythm never goes into backups, and that's enforced by design, not promised in a policy.
What didn't
Users barely noticed. This is the big one. Early on, people picked our suggestions for 0.9% of words. Things improved after the fixes, but the honest feeling stayed the same: the keyboard was better, and most people didn't feel enough of a difference to switch. A keyboard is muscle memory. "Better" isn't enough. It has to feel different in the first five minutes.
Scope kept growing. It started as a keyboard. Then autocorrect, swipe typing, voice dictation, on-device translation, even voice cloning. Each one was interesting. Together, they meant nothing got finished properly.
No real typing data. A privacy-first keyboard with few users doesn't generate data to learn from, and I refused to collect it. That was the right call ethically, and it capped how good the models could get. Most of our evals ran on synthetic data, which is a best case, not reality.
Some experiments just failed. A fine-tune to make an ASR model output romanized Hinglish directly came out worse than the simpler approach. That's normal, but it cost time I didn't have.
The money question
When I asked whether Keygram could ever be a sustainable business, I looked at the two closest examples. They taught me more than any model did.
FUTO Keyboard is probably the best privacy keyboard on Android, with offline voice and on-device models. Its license is a one-time payment, but it's honor-based: if you never pay, every feature keeps working and you just see a reminder. That works because FUTO doesn't need the keyboard to make money. It's funded by its founder, Eron Wolf, and says it isn't relying on VC or expecting quick profits.
Wispr Flow is voice dictation, not a keyboard, and it makes real money. Pro is $15 a month, or $12 billed yearly. The free plan stops at 2,000 words a week on desktop. Enterprise adds SOC 2, SSO and HIPAA controls. It raised $280M at a $2B valuation in August 2026 and says it has 100,000 businesses using it.
| Comparison | FUTO Keyboard | Wispr Flow |
|---|---|---|
| Who it's for | Privacy-minded phone users | Knowledge workers and companies |
| What it sells | Values | Time saved |
| Paywall | Honor system | Hard word limit |
| Where money comes from | The founder | Subscriptions, teams, compliance |
| Main platform | Phone keyboard | Desktop first |
What I took from it:
- People pay to get time back, not keystrokes. A lawyer dictating 3,000 words a day pays $15 without thinking. Someone saving a few seconds on a WhatsApp message won't.
- The phone keyboard is the hardest place to charge. Everyone expects it free, because the default one is free and good enough.
- The real money is in businesses. Compliance checkboxes, admin controls and team billing are boring and they pay the most.
- India makes it harder. Consumers here are especially price sensitive, and the big keyboards will keep getting better at Hinglish.
So the honest answer: Keygram as a consumer keyboard is a good product, not a business.
Why maintenance mode
Not because it failed technically. Because I finally asked the right question: who pays for this, and why? For a consumer keyboard in India, I don't have a good answer, and building more features wouldn't change that.
Keygram stays live. The engine underneath, the part that understands messy romanized Indian text, is the most valuable thing I built, and it might find a better home later in something businesses actually need.
What I'd do differently
- Ask "who pays?" in week one, before writing a line of code.
- Pick one feature and make it feel magic before adding the next. Five good features nobody notices lose to one great one people talk about.
- Ship and learn instead of redesigning. A shipped v1 teaches more than a tenth architecture rethink.
- Get real users early, even ten of them, even if it's uncomfortable.
- Keep the gates. That part I'd do exactly the same.
If you're building something similar for Indian languages, or you need help with romanized code-mixed text, I'd like to hear from you: hello@keygram.me.