Building for schools
What a K-12 platform runs into that a generic SaaS never does: procurement gates, the school day, and a network you do not control.
- Domain
- Education
- Notes
- 7 items
- Source
- Shipped work
- Reply
- Within a day
What I already knew before the kickoff call.
Shipped into a live K-12 platform serving 995 schools and 12,495 users.
Schools vet the software before they buy it
Australian and New Zealand jurisdictions assess school software through Safer Technologies 4 Schools, run by Education Services Australia. The Readiness Check is a free self-assessment; a full assessment is evidence-backed and the program itself advises allowing at least three months. Budget for it before the contract is signed, not after a school asks for the report.
Your deploy window is set by the timetable
A structural front-end change that invalidates client storage behaves very differently at 3am and at 9:15am. Ship anything that touches caching, sessions or service workers outside class hours, and keep the previous container renamed rather than deleted so the rollback is one command instead of a rebuild.
The school network is the constraint, not your server
Lessons have to survive a bad connection in a classroom, which makes offline availability a product requirement rather than a nice-to-have. Every course variant a school has licensed gets downloaded for local use.
Where this happened: K-12 Education SaaSA repeat visit should cost almost nothing
Static bundles were being re-fetched in full on every visit: 3.71 MB per returning user. Correct cache headers took that to 1.8 KB, and the same change removed 283 daily 502s that were coming from an unrelated default virtual host. Neither fix touched application code.
One curriculum is really a dozen curricula
Each state, board and school variant wants its own topic tree over broadly the same content. Model the variant as a first-class thing early. Retrofitting it into a single hardcoded tree is the expensive version of this lesson.
Where this happened: K-12 Education SaaS"The quiz is broken" is often "I got logged out"
When a token expires while several requests are in flight, each one can fire its own refresh. Two refreshes hit the same row, the loser gets a concurrency error and a 500, and the client logs the user out mid-session. From the student's side that looks like the quiz failing. Queue refresh behind a single promise, and read the access logs by timestamp instead of trying to reproduce it.
Single sign-on is not one integration
A department of education, a Catholic diocese and a bookseller each arrive with their own identity provider and their own quirks in the assertion. Treat each as its own piece of work with its own test account, and expect the reply-URL registration on the customer's side to be the slow part.
The same notes, other ground.
Working in one of these?
Tell me what is happening in your own words. I will tell you within a day whether it is mine to solve, and roughly what it takes.