In development · not yet released

Key Quest teaches children to type properly.

Most typing software for kids is one of two things: a drill they abandon inside a week, or a game that's genuinely fun and quietly teaches them to hunt and peck. Key Quest is an attempt at the third thing.

It isn't finished, and there's no release date. This page describes what's being built and why, which seemed more useful than a signup form.

The problem with typing games

Touch typing is one of the few skills where doing it badly for a year is worse than not doing it at all. Habits form fast. A child who learns to find keys by looking gets quicker at looking, and by the time speed matters the correction is painful.

The software mostly splits along an unhelpful line. Traditional typing tutors are pedagogically sound and unbearable — rows of asdf jkl; with a progress bar. Typing games are engaging and pedagogically indifferent: they reward hitting the right key, not hitting it with the right finger, so a child can get very good at the game while getting worse at typing.

The game has to want the same thing the lesson wants. Otherwise the child will optimise for the game, and they should.

How it works

Adaptive pacing
The app tracks per-key accuracy and latency, and builds the next lesson around whichever keys are actually lagging — not a fixed curriculum every child walks through at the same speed. A child who's fine with the home row but stumbles on b gets more b.
Accuracy first
Progression gates on accuracy before it gates on speed. Speed built on bad habits has to be unlearned later, and unlearning is much harder than learning.
Two-axis placement
New players are placed on two independent scales — which keys they know, and how fast they are with them — rather than a single level number. A fast hunt-and-peck typist and a slow correct typist need very different next lessons.
Built for three ages at once
The first test group is a Pre-K, a first grader, and a rising third grader in the same household. Anything that only works for one of them is the wrong design.
Offline and account-free
Native SwiftUI. No sign-in, no server, no analytics, nothing leaving the device. It works on a plane and it will still work in ten years.

Questions I'd ask

When is it coming out?

I don't know, and I'd rather say that than invent a quarter. This is a nights-and-weekends studio — I have a full-time job and three children. It ships when it's genuinely finished for the three kids it's being built for.

What will it cost?

Undecided, but there won't be advertising, and there won't be a subscription for something a child uses for a few months and then doesn't need. Those two things I'm certain about.

Is there a beta I can join?

Not yet. When there is, it'll be announced here first. There's no mailing list to join in the meantime — if you want to know, email me and I'll write back when there's something to say.

Will it be on Android, or the web?

Probably not. One person building natively for one platform can make something considerably better than one person building adequately for three. That's a real limitation and I'd rather name it than imply otherwise.

Why build this at all — hasn't it been done?

It has, repeatedly, and most of it is fine. I started because I watched my own children use the existing options and saw exactly where each one lost them. That's not a market analysis. It's just the honest reason.

If you want to know when it ships

There's no signup form and no newsletter. Send me an email and I'll reply when there's something real — a beta, a release date, or a note that it's been shelved.

hello@syntaxlabshq.com