School software teachers did not abandon
A school group with five branches and about 4,200 students
A group on its third attempt at school software, having twice bought systems that administrators used and teachers quietly ignored.
- Client
- A school group with five branches and about 4,200 students
- Industry
- Education
- Duration
- 9 weeks
- Team
- 3 engineers, 1 designer
- Year
- 2025
The situation
Two previous systems had been purchased and effectively abandoned because teachers found daily tasks slower than paper.
Attendance and marks were recorded on paper, then re-entered by office staff, producing a consistent lag and frequent transcription errors.
Each of the five branches ran a different fee structure and concession policy, which the previous systems could not represent.
Parents phoned the front office constantly for attendance, fees and results, consuming most of an administrator's day.
What we did
Designing for teachers first, administrators second
We spent the first week sitting with teachers rather than management. Attendance became three taps on a phone; marks entry became one grid per subject with keyboard navigation. Everything administrators needed was built on top of that data rather than requiring separate entry, because the previous failures came from asking teachers to do data entry that benefited someone else.
Fee structures as configuration, not code
Five branches with different structures, categories and concession rules meant fees had to be expressible as configuration. Hard-coding any branch's rules would have guaranteed a change request within a term.
A parent app answering the six common questions
We looked at what parents actually phoned about: attendance, marks, fee dues, homework, circulars and the school bus. The app answers exactly those six, and deliberately does nothing else.
Phased rollout across branches
One branch went live first for a full term before the others followed. The issues found in that term were mostly about teacher habits rather than software, and would have been five times as expensive to discover simultaneously.
The parts that were actually hard
Problem
Report card formats differed by branch and board, and management considered the exact layout non-negotiable.
How we handled it
We built a report card template system with per-branch layout, grading scale and remark structure, rather than treating the format as a fixed design. It took longer than hard-coding but avoided the rejection that had sunk earlier attempts.
Problem
Teachers in two branches had poor personal phones and weak school wi-fi.
How we handled it
The teacher app works offline for attendance and marks entry, syncing later. We also kept the app deliberately small, because install size was a genuine barrier on the devices in use.
What shipped
- Admissions, attendance, examinations, timetable and transport modules
- Per-branch configurable fee structures with online collection
- Offline-capable teacher app for attendance and marks
- Parent app covering attendance, marks, fees, homework, circulars and bus tracking
- Board-specific report card templates, configurable per branch
- UDISE+ export and consolidated cross-branch management reporting
Outcomes
- Teacher adoption held after the first term, which neither previous system achieved
- Attendance and marks are now available the same day rather than after office re-entry
- Front-office phone volume fell noticeably once the parent app covered the six common queries
- Fee collection timelines shortened after online payment and automated reminders went live
Outcomes are described qualitatively where no clean measured baseline existed before the work started.
Built with
Have a problem shaped like this one?
Tell us what you are dealing with. We will come back with a scoped estimate and an honest view on whether we are the right fit.