When we first started talking to school administrators about Kinderpedia, every conversation started with the same person: the deputy head. The procurement decisions, the contracts, the implementation discussions — all of them went through the administrative layer of the school. Teachers were not in the room. Their feedback was second-hand at best, filtered through someone who used the software differently, if at all.
That is exactly how most school management systems were built. And it is exactly why so many of them fail in practice.
The procurement problem
Software purchasing in schools follows a predictable pattern. A senior administrator identifies a problem — compliance reporting is taking too long, enrollment data is scattered, parents are calling reception instead of using an app. They look at two or three options, usually ones that came up in a conference presentation or a peer recommendation from another school director. The decision is made at the director level. The contract is signed. The teachers find out when they are required to attend a training session in November.
This is not unique to education. Enterprise software buying has always looked like this. The difference is that in most organizations, the people making the decision and the people doing the work overlap significantly. In schools they do not. A school director may teach two periods a week. The teachers who will mark attendance, enter grades, and send parent messages through the system every day are not the ones who evaluated it.
The result is systems designed to satisfy procurement criteria rather than daily use. They generate the reports that Ofsted or the Ministry of Education requires. They store the data fields that the inspection framework mandates. They produce the printouts the finance office needs for year-end. And they are genuinely painful to use for anything that happens before those reports get generated.
What teachers actually do all day
A secondary school teacher in a typical 600-student school interacts with approximately 120 students per week across 5 to 6 different classes. Every one of those interactions generates a data point that the school wants recorded: was the student present, did they submit work, what grade did they receive, was there a behavior incident, did a parent need to be notified.
The actual entry of that data — which happens during class, immediately after class, and during planning periods — is where most school management software creates its worst friction. Screens that require 7 clicks to mark a student absent. Grade entry forms that do not work on mobile. Parent messaging interfaces that look like a 2010 email client. These are not edge cases. They are the primary interface through which teachers experience the software every day.
We watched 23 teachers use the legacy SIS that one of our early customer schools had been using for six years. The average time to mark attendance for a class of 28 students was four minutes and twelve seconds on the desktop interface. It required logging into a separate portal, selecting the class from a dropdown, loading a new screen, marking each student, and saving. Four minutes per class, multiplied by 5 classes per day, multiplied by 190 school days: that is 63 hours of administrative time per teacher per year spent exclusively on marking attendance. Nothing else.
What we changed when we built the Kinderpedia teacher interface
The teacher interface in Kinderpedia was designed around a single constraint: it must work correctly and completely on a five-year-old Android phone held in one hand while standing at the front of a classroom. Everything else was secondary.
That meant the attendance screen needed to load in under two seconds on a 3G connection. It meant the default state assumed all students were present, so teachers only had to tap the ones who were absent — not confirm presence for every student in the list. It meant the save action was a single tap with visual confirmation, not a multi-step submission process. And it meant the whole sequence needed to take under 45 seconds for a class of 30, because that is the window before students start to lose focus during the start of a lesson.
We tested this with a group of teachers from three Kinderpedia customer schools in Romania in Q2 2024. The median time to mark attendance dropped from four minutes twelve seconds to forty-one seconds. The difference is not about the network speed or the device. It is about removing unnecessary steps from a task that happens five times a day, every day, for 190 days a year.
The grade entry problem is different
Attendance is simple: present or absent. Grade entry is more complex because grading is not consistent. Different subjects use different scales. Different teachers have different conventions. National grading frameworks in Romania, Bulgaria, and Hungary each work differently, and an international school using the IB programme adds another layer entirely. A system that forces all of these into a single rigid input schema is going to produce either enormous numbers of workarounds or data that does not accurately reflect what teachers actually assessed.
The Kinderpedia gradebook allows each subject to define its own assessment criteria and scales. A mathematics teacher can set up rubric-based assessments with weighted components. A physical education teacher can use a simple 1-10 national scale. A language teacher running Cambridge IGCSE can enter grades in the A*-G format that her certification body requires. The system calculates the transcript-ready grade in whatever format the school's reporting framework demands — the teacher never has to convert between systems manually.
This sounds obvious. It should be obvious. But the majority of SIS platforms in European private schools today present teachers with a single grade field and a text note. The conversion from the way teachers think about assessment to the format the system can store is done manually, by the teacher, every time.
Parent communication is the feature teachers care most about
In a survey we ran across 47 Kinderpedia customer schools in January 2025, teachers ranked parent communication as the single feature that had the biggest positive impact on their daily experience with the platform. Not grading. Not attendance. Communication.
The reason is straightforward. Before a unified communication channel existed, parent contact happened through WhatsApp groups, personal mobile numbers, the school's generic email address, and notes in the student's agenda book. All of these involved teachers using personal devices and personal contact details. The boundary between school time and personal time was non-existent for teachers who were responsive to parent messages. The teachers who set limits on their availability were considered difficult. Neither situation is good.
Kinderpedia's parent messaging goes through the platform entirely. Teachers respond when they are working. Parents receive responses when they are sent. The system timestamps messages and maintains a record that is visible to the school administration — which protects both teachers and parents in cases of dispute. Teachers do not share personal phone numbers. Parents do not have direct access to teachers outside of school hours unless the teacher explicitly enables that channel.
That structural separation is not a feature that appears in most procurement checklists. It is not something a deputy head in a budget meeting would identify as a priority. But it is the feature that teachers notice immediately when they start using the platform, because it changes how they relate to their evenings and weekends.
The offline problem in CEE schools
The conversation about school software usability in Western European contexts often skips an infrastructure reality that is very present in Central and Eastern Europe: internet connectivity in school buildings is unreliable. Not uniformly unreliable — some schools in Bucharest have better connectivity than most London schools. But enough schools in Romania, Bulgaria, and the MENA markets we serve that assuming constant internet access makes the software unusable for significant portions of the working day.
Kinderpedia's mobile teacher app caches the class lists, student profiles, and current timetable locally on the device. Attendance marks, grade entries, and behavior notes made while offline are queued and synced when connectivity returns. The teacher does not need to know whether she is online or offline. The app behaves the same either way. When we added this in version 3.4, the support ticket volume from schools in our Romanian Tier 2 city customer base — schools in Cluj, Timișoara, Iași, and Constanța — dropped by 34% in the first month. The issues were not software bugs. They were teachers trying to use a system that required a connection they did not have.
What getting this right actually costs
Building software that works for teachers rather than against them is not technically complex. The patterns — optimistic UI, offline caching, mobile-first forms — have been standard in consumer app development for a decade. The reason they do not appear in most school management software is not that they are hard to build. It is that the buyers of school management software are not the users, and the users have no voice in the buying process.
The cost of getting this wrong is real and measurable. A teacher who spends an extra three minutes per day fighting an attendance system loses 9.5 hours of instructional attention per year. Multiplied across a staff of 40 teachers, that is 380 teacher-hours per year spent on a single administrative task that should take 45 seconds. It shows up as stress, as cynicism about technology, and eventually as attrition — because teachers who feel unsupported by their tools do not stay.
The design decisions that make teacher-facing software genuinely useful are not expensive. The cost is in taking the time to watch teachers use the software before you ship it, and caring enough about what you see to change what you built.