I built a GCSE revision app for a student in my family. It’s live, it’s used daily, and it isn’t a pilot or a demo for anything else. This case study covers what the AI actually does, the measured timings that shaped the interface, and two design decisions that mattered more than the technology.
At a glance
| Type | AI-powered progressive web app |
| Built for | One GCSE student, eight subjects |
| AI jobs | Transcribe schoolwork, make notes, generate questions, generate topic questions |
| Measured timings | About 8s, 12s, 9s and 17s on the live build |
| Content | 234 study guide pages mapped across the eight subjects |
| Status | Live and in daily use |
The starting position
Revision apps mostly help with the easy half. Reading is easy to do and easy to fake. Being tested is the part that works, and it’s the part nobody has time to prepare, because turning a page of schoolwork into decent practice questions is a job in itself.
That gap is the whole reason the app exists. Everything he needs to revise should be inside it, and it should be simple and obvious to use.
What the AI does
Four jobs, each narrow:
| Job | What it takes | Measured time |
|---|---|---|
| Transcribe | A photo of handwritten or printed schoolwork | About 8 seconds |
| Notes | The transcribed text | About 12 seconds |
| Questions | The notes | About 9 seconds |
| Topic questions | A topic from the study guide list | About 17 seconds |
Those are timings from the live build, not estimates. They matter because a 17 second wait needs a different interface from a 2 second one. You design for the number you measured, which is an argument for getting something live early rather than designing against a guess.
The rest of the app is ordinary software. Keeping the AI’s job narrow is what makes the cost predictable and the output quality something you can judge.
How it’s structured
Eight subjects, shown as clear cards with an icon, the course, progress, questions due and a tick when that week’s work is added.
Each topic page runs three numbered steps. Learn it, which lists every study guide for the topic and ticks them off as he reads. Practise it, which offers the app’s own quiz alongside flashcard sets and exam questions. Then tick it off.
The structure came from a plain instruction: add everything so he can choose, but it all needs to be simple to follow, easy to use and have clear guides. That rewrite turned a capable app into a usable one, which isn’t the same thing.
Two decisions that mattered
Everything starts at “not started”. An earlier version pre-filled 20 topics as done, taken from existing checklists. That was removed, and a migration stripped it from accounts that already had it. Only progress made in the app counts. Imported progress looks generous and quietly removes the reason to do the work.
Usage limits went in from the start. 80 AI actions per account per day, and one sign-in code per address per minute. AI is billed per request, so an app without limits has an open-ended running cost. Putting the ceiling in before launch is much easier than explaining a bill afterwards.
The content work
Every study guide page for the eight subjects was read into the app’s own data: 234 pages, with a second pass to pick up the videos. Sciences, Geography and English Literature topics list all their guides. Maths, English Language and PE topics are single guides.
That’s the unglamorous half of a build like this. The AI is the interesting part and the content mapping is the part that makes it usable.
What I learned
Measure the AI steps on the live build before you design around them. The 17 second topic question job is the slowest thing in the app, and knowing that changed how the screen behaves rather than being discovered by a frustrated user.
The second learning is that pre-filled progress is a trap. It feels helpful and it undermines the only thing the app is for. Given the choice between an app that looks encouraging on day one and one that stays honest in week six, take the second.
Limitations
This is one student, one set of subjects, and no formal measurement of whether results improved. It’s a working tool rather than a study. AI output needs checking, and anything factual should be traceable to its source rather than trusted because it sounded right.
Services used
AI-powered apps, progressive web apps and app and tool development. A second version of the same idea, built for a school, is covered in the Tower Revision case study, and the education page covers the sector.
FAQ
What does the AI do in a revision app?
Four narrow jobs: reading a photo of schoolwork, turning that into notes, generating practice questions from those notes, and generating questions from a topic. Everything else is ordinary software. Keeping each job narrow is what keeps the cost and the output quality under control.
How do you stop the AI costs running away?
Limits, set before launch rather than after the first bill. This app allows 80 AI actions per account per day and one sign-in code per address each minute. Because AI is billed per request rather than a flat fee, an app without a ceiling has an open-ended running cost.
Is AI-generated revision material accurate enough?
For turning a source you already have into questions and notes, it’s genuinely useful, because the material comes from the student’s own work rather than the model’s memory. Anything factual should still be checked against the original, which is why the app links back to the study guides.
Can an app like this work for a school?
Yes, and a version built for one exists as a clickable prototype. The difference is that a school version needs teacher tools, a parent view and proper accounts, which is a bigger build than a single-student app and needs the school involved from the start.
Got a repetitive job worth automating?
Get in touch and describe what you’re currently retyping from one format into another. That’s usually where an AI step earns its place.