Tower Revision is a GCSE revision app built for an independent school. At the time of writing it’s a working clickable prototype that has not been deployed, sent or shown to the school. This case study covers why it was built that way round, and how the scope was kept deliberately small.
At a glance
| Type | Revision app for a school, clickable prototype |
| Realistic audience | About 56 pupils across Years 10 and 11 |
| Built | September 2026 |
| Testing | 19 test journeys, passing at phone and tablet size |
| Deployed | No |
| Shown to the school | No |
| Stack | Next.js, TypeScript, Tailwind, static prototype ready to deploy |
The starting position
The school is an independent school for ages 3 to 16, with a recent GCSE cohort of 28 pupils. That puts the realistic audience at around 56 pupils across two year groups.
That number is the most important thing on this page. A 56-pupil audience rules out anything with a heavy per-user cost or a long build, and it rules out the temptation to turn a revision app into a school management system.
What it does
Two strands.
The first remembers what a pupil has studied, turns school work into revision, tests them on it, and brings each topic back before they forget it.
The second is booster sessions. A session run by a teacher becomes searchable notes, flashcards and questions instead of disappearing when it ends. That’s the part that’s genuinely hard to do any other way, because the material only exists while the session is happening.
What was deliberately left out
Built for the pupil first. The school view is limited to adding booster sessions, papers and the booster timetable. The parent view is a short weekly check-in.
There’s no timetabling, no registers and no school management. Those are the features that make a schools product expensive to build, slow to sell and hard to support, and none of them help a pupil revise. Saying no to them in the scoping was the single decision that kept this buildable.
Why prototype before pitching
The prototype was built and tested before the school had seen anything. Nineteen test journeys pass at phone and tablet size.
There’s a reason for that order. A school can’t usefully react to a description of an app. It can react to something it can hold and click through, and the questions it asks then are the real ones. Building the prototype first also means the estimate for the real thing is based on something that exists rather than on optimism.
The back end, meaning logins, a database and the AI, isn’t built. It’s planned and costed, waiting on the school. That’s the honest position, and it’s better than a half-built system nobody has agreed to pay for.
What I learned
Scope a schools product by its smallest realistic audience, not its most ambitious one. At 56 pupils, every feature has to justify itself against a very small denominator, and that constraint produced a better app than a bigger assumed audience would have.
The other learning is about the order of work. Prototype, test, then pitch. The temptation is to pitch the idea and build once it’s agreed, but a prototype costs days and turns a speculative conversation into a concrete one.
Limitations
This hasn’t been deployed or shown to the school, so there are no adoption figures, no pupil feedback and no outcomes to report. The intro screen wording is incomplete.
Services used
AI-powered apps, progressive web apps and app and tool development. The single-student version that is live is covered in the AI revision app case study, and the education page covers the sector.
FAQ
Why build a prototype before showing the school?
Because a school can’t react usefully to a description. Given something they can click through, the questions they ask are the real ones. It also means any estimate for the full build rests on something that exists rather than on an optimistic guess about scope.
Why leave out timetabling and registers?
They’re the features that make a schools product expensive to build, slow to sell and hard to support, and not one of them helps a pupil revise. Leaving them out kept the app small enough to be worth building for an audience of around 56 pupils.
What happens to a booster session normally?
It ends, and the material goes with it. Turning a teacher-run session into searchable notes, flashcards and questions is the part of this app that’s hardest to replicate any other way, because the content only exists while the session is actually running.
How small can an audience be and still justify an app?
Smaller than most people assume, provided the build is scoped to match. At around 56 pupils this works because the feature list was cut hard. The same app with school management features attached would not have been worth building at that size.
Thinking about an app for a small audience?
Get in touch and tell me how many people would genuinely use it. That number should shape the build rather than be discovered afterwards.