Alihocaedu — Turning Exam Results into Progress
Alihocaedu is the practice of a mathematics teacher who works with primary, middle, and high school students preparing for Turkey's national exams. Every couple of weeks his students sit a practice exam, and every couple of weeks the same routine followed: collect the answer sheets, calculate nets by hand, note the numbers down somewhere, and try to remember how each student was doing three exams ago.
The teaching was never the problem. The tracking was.
The challenge
A practice exam result on its own says very little. A student scoring 62 net means nothing until you know they scored 54 last month and 49 the month before — and that almost all of the gain came from a single subject while another quietly slipped.
That comparison is exactly what manual tracking makes expensive. Three specific problems:
- Net calculation differs by exam type. LGS and primary-level practice exams use
correct − wrong ÷ 3; TYT, AYT, and YDT usecorrect − wrong ÷ 4; a school exam has no formula at all. Doing this by hand across every subject, every student, every exam is both slow and error-prone. - Progress lives across exams, not inside one. The signal a teacher actually needs — is this student improving, and in which subjects — only appears when results are stacked over time.
- Students and parents were outside the loop. Everything a parent knew came through a phone call or a meeting. There was no place to look.
There was one more constraint that shaped the whole build: this is one teacher's tool, not a product for sale. No public signup, no organizations, no billing. Building it as a multi-tenant SaaS would have added a layer of complexity that nobody would ever use.
What we built
We designed and built Alihocaedu — a single-tenant tracking platform with four roles that each see a purpose-built portal over the same data.
Exam and result entry:
The teacher creates an exam with its type, level, publisher, subjects, and question counts, then assigns it to a class or to individual students. Results are entered per student per subject — correct, wrong, blank — and net is calculated on the spot from the rule matching that exam type, with an override available for anything custom. Exams stay in draft while results are being entered and only become visible to students once published.
Progress analysis:
Net trend and subject-level charts turn a stack of exams into a shape. Strong subjects, weakening subjects, and the trajectory between them are visible without anyone lining up old papers on a desk.
AI-drafted student analysis:
After an exam, the teacher can generate an analysis of a student's recent performance. The model returns a structured summary — general assessment, strong subjects, subjects needing support, and study suggestions — as a draft. The teacher edits it, approves it, and only then does it reach the student and parent. The original model output is stored unchanged alongside the edited version.
Homework:
A deliberately simple module. The teacher assigns homework with a subject, topic, and due date, attaches a PDF, and marks it done or not done per student. No submissions, no grading — the workflow that was actually being used, not the one a generic LMS would impose.
Student and parent portals:
Students see their latest result, subject nets, progress against previous exams, approved analysis notes, active homework, and their weekly schedule. Parents see the same picture for each of their children. Accounts are created only through a tokenized invitation link sent by the teacher.
Teacher's own layer:
Alongside student data, the teacher has a weekly calendar for lessons and prep, a parent-meeting log recording agenda, notes, and decisions from each conversation, per-student weekly schedules, PDF student reports generated server-side, and global search across the dashboard.
The outcome
The loop that used to run on paper now runs on its own.
Nets are never calculated by hand — the formula is picked from the exam type at entry time. Progress is never reconstructed from memory — it is a chart. A parent asking "how is she doing?" no longer needs a phone call scheduled around the teacher's day; they open their portal and see the same numbers the teacher sees.
The AI analysis changed the economics of a specific task. Writing a considered paragraph about one student's trajectory takes real time, and doing it for every student after every exam is not realistic. Generating a grounded draft that the teacher then corrects and approves is. The teacher's judgment still decides what a student reads — the model just removes the blank page.
And because the platform was scoped as one teacher's tool from day one, none of it is buried under features built for an institution that does not exist.
"CzayLabs ile deneme takip sistemi projemiz için çalışma fırsatımız oldu. Süreç boyunca iletişimleri çok iyiydi; taleplerimi dikkatle dinleyip projeyi tam istediğim şekilde ve zamanında teslim ettiler. Hem çalışma disiplinlerinden hem de ortaya çıkan sonuçtan çok memnun kaldım. Gönül rahatlığıyla tavsiye ederim."
— Mehmet Ali Satar, Matematik Öğretmeni, Alihocaedu
What we learned
The most consequential decision was freezing net values at write time instead of computing them on read. Formulas are configurable, and a configurable formula that recalculates history is a trap: change a divisor today and every chart in the system rewrites itself, quietly invalidating a year of comparisons. Storing the net that was true when the result was entered keeps the past stable.
The second was making AI output a draft by default rather than a result. Student-facing commentary is high-stakes — a model that is confidently wrong about a child's performance costs more than it saves. Routing every analysis through teacher approval, keeping the raw output separate from the edited text, and sending anonymized references instead of names to the model made the feature something the teacher could actually put his name behind.
The third was resisting scope that sounded reasonable. Homework submissions, grading, attendance, multi-tenancy — each was easy to justify in the abstract and none matched how this practice actually runs. Building the workflow in front of us produced a tool that gets used daily instead of one that gets configured once.
Planning a platform built around how your work actually runs? Get in touch and we'll walk you through what a scoped build would look like.