What it takes to build a revision platform that marks handwriting
Ilmino marks typed and handwritten student work against a mark scheme, across a question bank in the tens of thousands. Here is what that actually required, and where the hard parts were.
Ilmino is the largest thing we have built, and unusually for an agency project, we own and operate it. That changes what you learn. When you run the platform yourself, you find out which parts were badly designed, because you are the one fixing them at half past ten on a Sunday.
It is a GCSE and A-Level revision platform. Students practise exam-board-aligned questions, submit typed or handwritten work, and get feedback against the mark scheme rather than a right or wrong tick. Behind it sits a NestJS API on PostgreSQL, a Next.js student application, and a Flutter build for mobile, all sharing one data model.
The question bank was the real project
Everyone underestimates content. A revision platform is only as good as the questions in it, and a bank in the tens of thousands cannot be written by hand. Nor can it be generated carelessly, because a wrong question in an exam platform is worse than no question at all.
So the question bank is itself a piece of software: a generation, verification and quality-gating pipeline. Questions are produced against a specification, then independently re-solved, then sampled for review. Anything that fails is rejected rather than fixed, because a plausible-looking wrong answer costs more to find later than it does to discard now.
The lesson that cost us most: measure coverage against the specification, not against how many questions you have produced. Ten thousand questions clustered on the easy topics is not a bank, it is a pile.
Marking handwriting is a product problem, not a model problem
Reading a photograph of a student's working is the easy half. The hard half is deciding what to do when the model is unsure, because in education a confident wrong mark is genuinely damaging. A student who is told their correct method is wrong will not trust the platform again.
What that meant in practice:
- Marking against the mark scheme's steps, so partial credit is possible rather than a single verdict
- Confidence thresholds, below which the work is flagged rather than marked
- A teacher override on everything, with the original submission always retrievable
- An evaluation set, so a prompt or model change is a measurement rather than a hope
Three things we would tell anyone building in this space
First, integrate with the school's existing systems early. A platform that does not talk to the management information system gets abandoned, however good it is, because nobody will maintain two sets of student records.
Second, design for the teacher, not the demo. Adoption is decided by whether marking a set of thirty is faster than it was on paper. Everything else is secondary.
Third, know your cost per run before you scale. AI features scale their cost with usage, and unit economics that work at a hundred students can be ruinous at ten thousand. Model routing, caching and batching are not optimisations you add later, they are design decisions.
If you are building a learning platform and any of that sounds familiar, we have already made most of these mistakes and would rather you did not have to.