The School Website Is Dead. Long Live the School App.

Open ten Polish school websites at random. You will find news from three months ago, a row of ministry logos, and a “documents” page that is a wall of scanned PDFs. Sometimes a visitor counter, faithfully counting since 2009.

This is not because schools don’t care. It is because we have collectively decided that a school website is a noticeboard — a compliance artifact that exists so that nobody can say it doesn’t. And a noticeboard has no users. It has passers-by.

The thesis

A school website should be an application.

Not “responsive.” Not “modern-looking.” An application: something a parent installs on their phone, that notifies them when something happens, that answers their questions when the secretariat is closed, and that is always — not usually, always — up to date.

That sentence sounds expensive. It is not. We rebuilt our school’s site on exactly this premise, and the monthly running cost is zero. Not “low.” Zero. That is not a promotional claim; it is an architectural decision, and I will explain it below.

What it looks like from the parent’s side

The effects first, because the effects are the point.

A parent visits the site once and gets a prompt to install it. From then on it lives on their home screen like any other app. When the school publishes news — a schedule change, a trip reminder, exam results — a push notification arrives on their phone within seconds of the editor pressing “publish.” No newsletter that lands in spam. No third-party parent-messaging app with an account, a password, and a subscription.

At 10 PM, a parent considering enrollment asks the site’s assistant how admissions work for first grade. They get an answer drawn from the school’s actual documents — the real deadlines, the real requirements — because the assistant is grounded in a curated knowledge base the school maintains, not in whatever a language model feels like improvising. If the answer isn’t in the knowledge base, it says so and points to the secretariat.

A grandmother with poor eyesight opens the accessibility panel and gets larger text, higher contrast, and text-to-speech. The whole site loads near-instantly, scores a full 100 across Lighthouse’s categories, and works offline for content already visited.

None of this is science fiction. All of it is boring, proven technology — just technology that school websites have decided is not for them.

What it looks like from the inside

The stack, at the altitude that matters: a static-first framework (Astro) generating fast pages; Firebase for hosting, data, and the small number of server functions that genuinely need to exist; Gemini powering the assistant; the whole thing living inside the Google ecosystem the school already uses for everything else, as a Google for Education Reference School.

The zero-cost claim rests on three decisions. First, static by default: almost every page is pre-built and served from a CDN, which costs nothing at a school’s traffic scale. Second, serverless for the rest: functions run only when called — a push dispatch, a chatbot answer — and a school’s volume sits comfortably inside free tiers. Third, no vendors: no CMS subscription, no parent-communication SaaS, no chatbot-as-a-service. The school owns every piece.

I am deliberately not publishing an architecture walkthrough here. Partly because a school website is public infrastructure and discretion is part of security hygiene; mostly because the architecture is not the interesting part. The interesting part is that a school — one person at a school, honestly — can now assemble this from components that cost nothing and are documented to death.

What broke, and what is hard

The practitioner’s section, because posts without one are advertising.

Push notifications on Apple devices are the single largest source of friction. iOS requires the site to be installed to the home screen before notifications work at all, and macOS quietly requires the user to enable them in System Settings. Nothing in the technology warns you; parents just report that “notifications don’t work,” and you learn the hard way that the onboarding instructions matter as much as the code.

Making a PWA and push notifications coexist means running two service workers side by side, and they are not naturally friendly. Getting caching and messaging to stop fighting each other took longer than any feature on the site. If you attempt this, budget real time for it.

And the honest, uncomfortable one: the bottleneck is editorial, not technical. A push notification about nothing is spam. A chatbot with a stale knowledge base is a liar with good manners. An app-grade website demands app-grade content ownership — someone who updates the knowledge base when the admissions rules change and thinks twice before pressing the button that pings four hundred phones. Solve that organizational problem first; it is harder than the code.

Can your school do this?

The uncomfortable answer: today, only if someone on staff can build it or the school hires someone who can. The honest counterweight: that barrier is collapsing fast. Every component here is free, documented, and increasingly assembled with AI assistance rather than written line by line. I am preparing a generalized, school-agnostic tutorial for exactly this stack — it will appear on this site.

The paradigm is the part you can adopt today, at any school, regardless of stack: stop treating the website as a noticeboard. Ask what a parent needs at 10 PM on a Tuesday, and judge every element of your digital presence against that question.

The live example is here: podstawowa.piwoni.pl. Install it. Poke the assistant. Break something and tell me.

A question for those running school communications: what would it take for parents to treat the school’s own channel — not a Facebook group, not a paid messaging app — as the place where school information lives? I have my hypothesis. I would like to hear yours.