Some education products look excellent in a demo and fail in week one. They are fast, modern, pleasant to use, and built by people on office fibre with a recent laptop. Then they arrive in a secondary school where three hundred pupils open them simultaneously at nine o’clock on a Monday, through one contended connection, on devices that are four years old and shared.
Contended means the connection is being shared by many people at once. On paper, nothing is broken. Every request eventually succeeds. The product loads. The server responds. But a lesson has thirty five minutes of usable time in it. If the first eight are spent waiting, the teacher will not use the product again.
A good demo can still fail in the first lesson
The business problem is simple. Education software is judged in the room where it is used. A polished interface and a strong feature list do not help if the first part of the lesson is spent watching spinners.
The load in a school is different from the load most teams test against. It comes from a timetable, from shared devices, from managed browsers, and from whole cohorts doing the same thing at the same time. That makes bandwidth a design constraint from the start.
School traffic arrives in one predictable rush
Consumer software has a diurnal curve, with use rising and falling through the day. Education software has a timetable. Timetables are synchronised across an entire institution, and often across a whole region.
Everyone starts at the same time. Everyone submits before the same deadline. Everyone opens the same resource because it was on the same slide.
That traffic profile is closer to a ticketing system than a content site. The ratio between the busiest minute and the average minute is enormous. The busy minutes are also entirely predictable.
That predictability is the opportunity. Unlike a retailer guessing at a campaign, you know the school day. You can pre-warm, pre-generate and pre-position almost everything, because you know what Monday at nine looks like before it happens.
Slow lessons usually come from small design choices
When we are asked to fix an education platform that is struggling, the cause is rarely raw server capacity. It is usually one of these.
- Payload weight. A three megabyte initial load is invisible on fibre and brutal on a contended school link shared by four hundred people. Multiply by three hundred simultaneous users and you have saturated the building.
- Chatty startup. Forty small requests before the first useful pixel. Each one costs a round trip, the time taken to go to the server and back, and round trips on a congested link are where the latency actually lives.
- Assets that are not cached at the edge of the building. Every pupil downloading the same video individually through the same pipe.
- Authentication that round trips to a national identity provider on every navigation.
- Autosave that fires per keystroke. Sensible on a fast connection, a self-inflicted denial of service on a slow one.
None of those are hard problems. They are problems that stay invisible unless you test in conditions that resemble the building.
Test builds on a school-like connection
We keep a throttled profile that approximates a contended school link. Throttled means deliberately slowed down to match the connection the product will meet. We run the critical journeys through it as part of the build, rather than leaving that work to a pre-release check.
The numbers are deliberately unkind: a few megabits shared, latency in the hundreds of milliseconds, occasional packet loss.
Running that continuously changes design decisions early, when they are cheap. A component that needs six requests to render gets rebuilt as one. A library that adds four hundred kilobytes for one function gets replaced. Nobody argues about it, because the number is on the screen next to the pull request.
The usual alternative is discovering all of this in a pilot. By then, the fixes are architectural, and the pilot has already formed an opinion.
School devices change the design
The hardware in schools is older, shared, and frequently running a browser that is a version or two behind because updates are managed centrally and cautiously. That has consequences beyond performance.
Shared devices make session handling visible
Shared devices mean session handling has to be explicit. A pupil who does not log out and a device handed to the next class is an ordinary Tuesday. If your product treats a session as durable, you will attribute one child’s work to another.
Older devices make memory matter
Memory matters too. A single page application, where the browser keeps much of the product running on one page, may grow steadily over a lesson. It will be fine on a development machine. It will be terminated by the browser on a four year old device with two gigabytes of memory.
Keyboard and touch both have to work
School hardware also means keyboard and touch both have to work properly, because you do not know which one is in the room.
Short connection drops still lose trust
Connections in schools drop. Usually this is not for hours. It may be for the ninety seconds it takes for a wireless access point to be overwhelmed by a class arriving.
If your product loses work in that window, the teacher learns not to trust it. Trust is the whole game.
The pattern we use is the same one that works on a construction site: capture locally first, sync afterwards, and never make the person wait for the network to know their work is safe. The interface says saved when it is saved on the device. It then shows a quiet, honest indicator while it catches up. That single decision removes the most common complaint in the sector.
Safeguarding has to shape the data model
Education software carries obligations that consumer software does not. Those obligations cannot be satisfied by adding a policy document at the end.
Who can see a child’s work, for how long, and on whose authority is a data model question. So is what happens when a pupil moves school, when a parent requests access, or when a safeguarding concern requires that a record be preserved and not edited.
If those are afterthoughts, the answers are all bad. They tend to be discovered during procurement rather than during design.
We treat the access model the way we treat an audit trail in healthcare: as an append-only record of who saw what and under which role, decided at the start. Retrofitting it means touching every query in the system.
Schools buy for years, so the exit matters
Schools and multi-academy trusts do not switch platforms casually. The real cost of a migration is retraining several hundred adults, moving years of pupil records, and absorbing a term of reduced confidence.
That makes the buying decision closer to infrastructure procurement than to software purchasing. It also makes questions that seem paranoid entirely reasonable.
Those questions usually include several difficult areas.
- What happens to the data if the supplier is acquired.
- Whether an export is a real export or a comma separated file with the interesting fields missing.
- Whether the integration with the management information system is supported by both parties or by one of them hopefully.
- Whether the product will still run on the devices the trust has already bought, for the four years it intends to keep them.
We answer those in writing, including the ones where the honest answer is unflattering. A supplier who is vague at this stage is telling you what the relationship will be like in year three. The same argument we make about handover elsewhere applies with more force here: the exit is part of what is being bought.
Accessibility decides whether a child can take part
In a consumer product, an accessibility failure is a bug and a legal exposure. In a classroom, it is a child who cannot do the lesson while sitting next to thirty children who can. That is a different order of problem entirely.
The practical consequences are unglamorous.
- Keyboard navigation has to work for the whole journey, not most of it, because some pupils do not use a mouse.
- Contrast has to survive a projector and a sunlit room.
- Text has to reflow at two hundred percent zoom without horizontal scrolling.
- Anything conveyed by colour needs a second signal.
- Screen reader labelling has to be correct on the interactive parts, where most implementations quietly give up.
We build these in as acceptance criteria rather than as an audit at the end. Retrofitting accessibility into a component library is one of the more expensive things you can do to a codebase, and doing it late guarantees it is done badly.
Integration failures look like lost work
Nobody plans for this properly. A school platform that does not talk to the management information system is a platform that requires somebody to type the same class lists twice. That person will stop.
So integration is not optional. In this sector, integration means several incompatible systems, different data models for the same concepts, and sync windows measured in overnight batches.
The failure mode is subtle. A pupil moves tutor group in the MIS on Tuesday. Your platform learns about it on Thursday. For two days, work is filed against a group that no longer exists. The teacher who cannot find it concludes the product lost it.
We design for that lag explicitly: records belong to a pupil rather than to a group, group membership is a time-bounded fact rather than a property, and the interface can answer “where did this go” without anybody opening a database.
The first four minutes decide adoption
The feature list is not what teachers judge first. They judge whether the product works in the first four minutes of a lesson with thirty adolescents in the room, some of whom would prefer it did not.
That means the login has to be fast and forgiving. Recovery from a forgotten password cannot involve email a child does not have access to. The teacher needs a way to see, at a glance, who is actually in and working.
Everything else can be excellent, and the product will still be abandoned if that opening is unreliable.
We have learned to build that specific journey first and defend its performance budget more aggressively than anything else in the system. It is the only part where a bad day is visible to thirty people at once.
The measures are tied to the lesson
We measure the parts that decide whether the product works in the room.
- Time to first useful interaction, at the 95th percentile, on the throttled profile.
- Total bytes on the first load, and on a repeat visit the following day.
- Requests before first paint.
- Concurrent sessions the system sustains when they all begin within sixty seconds.
- Work lost per thousand sessions, which should be zero.
The last one is the one clients find unusual. Most platforms do not measure lost work because measuring it requires admitting it happens. We instrument it explicitly: a draft that existed on a device and never arrived on the server is a counted event, and it has an owner.
A small rebuild made the pilot usable
A platform we took over had an initial load of 4.1 megabytes and thirty eight requests before anything useful appeared. On office broadband it felt instant. In the pilot school it took between nine and twenty two seconds depending on how many other classes were online. The deployment was three weeks from being cancelled.
We did not rearchitect it. We changed the parts that mattered.
- We split the bundle so the first screen needed 380 kilobytes.
- We moved the resource files to an edge cache.
- We collapsed the startup calls from thirty eight to four.
- We made autosave batch on a two second idle rather than firing per keystroke.
That was nine days of work.
Time to first interaction at the 95th percentile went from nineteen seconds to 2.4. Nothing about the product changed. The same features, the same design, the same server capacity. It simply became usable in the building it was sold into, which is the only measure that ever mattered.
More on how we work in this sector on our education page.
