The criteria were in the teacher's head. That was the problem.

A learning center was running homework review through three Telegram bots. Students submitted work, the bots routed it somewhere, a teacher checked it by hand, grades ended up in a Google Sheets file. It worked after a fashion.

The brief was to replace the bots with something better.

Before writing a line of code, we read the entire course.

There was no list of assignments. There were no written evaluation criteria. The requirements for each submission existed inside the course content and inside the teacher's experience, but nowhere else. The teacher knew what a good presentation looked like. The bots did not. This is why the review process required so much manual work: without explicit criteria, the only person who could assess a submission was the person who already knew what to look for.

We extracted 14 assignments from the course and turned each one into a structured specification. Every criterion was tagged as required or optional. Every rejection reason was written down in plain language a student could act on. The specifications were stored as JSON: versioned, reusable, unambiguous. Only after that work was done did we build anything.

One app replaced all three bots.

A student opens the app and sees their active assignment, the deadline, and one button. They submit their work in any format: text, photo, video, slide deck, document. They can shoot directly from the camera inside the app. Files go to Google Drive. The student is released immediately while the review runs in the background.

The review checks the submission against the structured criteria for that assignment. If the work is rejected, the student receives a numbered list of specific things to fix, with a reference to the exact criterion each item fails. Not a vague score, not a generic comment: a concrete list. Item one, item two, item three. The student revises and resubmits.

The teacher sees a feed of incoming work with the review result already attached. Accepted, rejected, or flagged for manual attention. The teacher reviews the result, looks at the submission, and gives the final grade. Work that doesn't require a specialist's judgment doesn't reach the teacher. Work that does, reaches them with the context already prepared.

The teacher can return work to the student for revision with a written comment. They can override the automated review and grade manually. For assignments that don't lend themselves to automated checking, the review step is skipped entirely.

The ranking shows each student their position in the class, their score, and the gap between them and the top. Other students appear as animals: a panda, a hedgehog, a fox. The animal mask each student sees for their classmates is unique to them, so the class can't collectively identify who is falling behind by comparing what they see. The gap in numbers stays visible. The names don't.

Twice each day the system posts a class summary to Telegram: how many students have submitted, how many are in revision, how many haven't started. The teacher gets this without opening the app.

How we built it

We wrote the backend from scratch on Express and TypeScript with raw SQL over PostgreSQL. The bots' domain logic was ported directly: same data model, same business rules, different infrastructure. The bots were switched off.

The whole system runs on our own VPS. No third-party limits. No free tier throttling. Credentials for all external services live only on the server; the client talks to our API and nothing else.

Three things required non-obvious solutions.

The first was concurrency. If a student submits five files in quick succession, only the first should be processed. We handle this with a single atomic database update that claims the submission before processing starts. A student can't burn through their attempts or the review budget by submitting too fast.

The second was load. Under a burst of simultaneous submissions, the review service hit rate limits and returned errors to students. We built a persistent queue backed by the database: the student is released immediately, a worker processes submissions one by one, retries on failure, and after several failed attempts routes the submission to the teacher for manual review. The queue survives a server restart.

The third was geography. The review service doesn't operate from certain server locations. The production system was returning errors that looked like an intake failure. We moved the backend to a VPS in Tashkent and turned the original server into a reverse proxy. Students who had already installed the app didn't need to update anything.

The app runs on Android, iOS, and web from a single codebase. Two weeks from the first conversation to a working system in production.