The criteria were in the teacher’s head. That was the problem.
A learning center ran homework review through three Telegram bots, a teacher checking by hand, and grades in a spreadsheet. The brief was to replace the bots. The real work came before the first line of app code.
- Services
- Custom SaaS development, AI automation
- Year
- 2026

Results
3→1
Telegram bots replaced by one app
34
students in production
14
assignments structured from the course (11 homeworks, 2 exams, a project)
~2 wks
from first conversation to production
What was missing
Students submitted work — text, photo, video, slide decks — into three Telegram bots running on n8n, Supabase and Gemini. Domain logic was scattered across n8n nodes, the free tier throttled the project, the grade log lived in Google Sheets, and neither student nor teacher had a single interface. The teacher had no time to review every submission by hand and explain what each one needed to fix.
Before
- Three Telegram bots on n8n, Supabase and Gemini
- Logic scattered across n8n nodes — fragile and opaque
- Free Supabase tier throttling the project with limits
- The grade log kept in Google Sheets
- No single interface for either student or teacher
The insight
There was no list of assignments and no written evaluation criteria. The requirements lived implicitly in the course and in the teacher’s experience — which is exactly why review needed 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 read the entire course and turned it into a structured, machine-readable specification — 14 assignments, each criterion tagged required or optional and paired with a plain-language rejection reason — before building anything.
What we built
One app replaced all three bots. A student submits work in any format and is released immediately while review runs in the background; if the work is rejected, they get a concrete numbered list of what to fix, each item referencing the criterion it fails. The teacher sees a feed of incoming work with the review result already attached, and gives the final grade. The bots’ domain logic was ported 1:1 into an Express API with raw SQL over PostgreSQL on the client’s own VPS — no third-party limits, no credentials in the client bundle. Three problems needed real engineering: an atomic work-claim so a fast submitter can’t burn their attempts; a DB-persisted retry queue that survives restarts under load; and a move to a Tashkent VPS with a reverse proxy after the review service refused certain server locations. A pseudonymous ranking with per-viewer animal masks keeps the score gap visible while hiding who’s behind.
After
- One app: student submits → structured review → teacher grades
- Evaluation criteria written down and versioned before any code
- A numbered, actionable list of what to fix on every rejection
- PostgreSQL on the client’s own VPS, no third-party limits or leaked secrets
- Running in production on Android and web at alfahw.alfakom.uz

The student home screen: the current assignment, its status and the next step. 
The pseudonymous class ranking, ordered by completed homework with per-viewer animal masks. 
The teacher workspace: incoming work for an assignment across 34 students, ready to grade.
Stack
Next case
They asked for a payment button. We looked at what they actually had.Talents Music School
Read the caseContact
Want one of these?
Tell us what is not working. We will tell you what we would do about it.
- Response time
- We answer within one working day.
- How we work
- A remote-first team across EU and US time zones. Everything runs online — your meetings happen where your team already is.