Case record · Education

A school website built around
one admissions season.

Around 400 gallery images, a dozen downloadable documents, and a front office that needs every enquiry in one place. Five weeks from discovery to live, deliberately finished before the January admissions rush began.

Open school.narvyn.com

Record NIS-01

The engineering record

Sector
Education — school admissions and campus site
Live at
school.narvyn.com
Stack
Next.js 14 (App Router) · TypeScript · Tailwind CSS · PostgreSQL · Object storage for media
Timeline
5 weeks, discovery to live
What it carries
About 400 gallery images and a dozen downloadable documents; enquiries run in the low tens per day, peaking through the January–March admissions window

built for a season, not for a launch

school.narvyn.com — admissions-first school website with academics, gallery and campus visit booking
Captured from the live deployment. Admissions is the spine of the site rather than a tab at the end of the navigation.
The briefa school website has one season

Everything points at admissions.

A school website is not a year-round marketing asset in the way a company website is. It has a season. From roughly January to March, parents in the catchment are comparing four or five schools at once, mostly in the evening, mostly on a phone, and mostly while a second parent looks over their shoulder. For the rest of the year the site serves existing parents looking for a circular or a date. Those are two different jobs and only one of them decides whether the school fills its intake.

So the structure follows the admissions decision rather than the school's org chart. A parent comparing schools wants to see the place — real photographs of real classrooms, not stock images of a laboratory nobody recognises — then check the practical facts, then either enquire or book a visit. Roughly 400 photographs went into the gallery for exactly that reason: in this category, the photographs are the argument.

The second half of the brief was not visible to parents at all. The front office is one or two people, and during the peak they are answering the phone while a parent stands at the desk. Any system that gave them a second inbox to remember would have been abandoned inside a fortnight, and the enquiries that fell through it would have been the school's actual revenue. Most of the engineering decisions below come from that constraint rather than from anything a visitor sees.

Decisionsthe choice, the reason, and the consequence

Three calls that shaped the build.

Decision 01

Admissions enquiry and campus-visit booking share one stored record with a type flag.

Why

The front office follows up both the same way. One table meant one inbox, one export and one place to look when a parent calls back.

What it means in practice

The obvious design is two forms, two tables, two notification emails and two exports — because they are two different things. The obvious design is wrong here, and the reason has nothing to do with software. The front office does not think of them as different things. Both are a parent who is interested, both get the same phone call within a day, and both need to be visible to whoever picks up when that parent rings back.

One table with a type flag means one place to look, one export for the principal, and no scenario where an enquiry sits unanswered in the inbox nobody opened this week. When we later needed to count enquiries by month for the admissions review, the query was one line rather than a reconciliation.

Decision 02

Gallery images are pre-processed into responsive AVIF and WebP at build time.

Why

Most parents open the site on a mid-range Android over mobile data. Shrinking the gallery payload mattered more to them than any animation we could have added.

What it means in practice

Four hundred photographs is the point at which a school website either works on a phone or does not exist. Uploaded straight from a camera, that gallery is tens of megabytes per page — which on a mid-range Android over a patchy mobile connection is not a slow page, it is a closed tab.

Generating responsive AVIF and WebP versions at build time moves that cost to us, once, instead of to every parent, every visit. The gallery loads at a fraction of the original weight and the photographs still look like the school.

We are stating this plainly because it is where a real budget decision gets made. Given a fixed number of days, an image pipeline is less impressive in a demo than a scroll animation, and it is worth considerably more to a school in March. We would spend the days the same way again.

Decision 03

Content pages are editable; structure is not.

Why

Staff needed to change fee tables and dates without us. Letting them also move sections around would have broken the admissions path within a term.

What it means in practice

Staff can change fee tables, dates, circulars and page copy without calling us — those change on the school's timetable, not ours, and waiting on a developer to publish a revised fee schedule is an absurd way to run a school.

What they deliberately cannot do is move sections, reorder navigation or delete the admissions path. Full page-builder freedom sounds generous and reliably ends the same way: a term later, the enquiry button is below three new sections somebody added in good faith, and nobody connects the drop in enquiries to the change.

Editable content, fixed structure is the line we now draw by default on every site where a form is the point. It is the same principle behind our school fee management system: the school controls the data, we hold the workflow steady.

The numbersand why the calendar matters more

Enquiries in the low tens per day.

Day to day the site carries enquiries in the low tens, peaking through the January to March admissions window. That peak is the entire commercial story of a school website, and it changes how a project like this has to be run.

A five-week build that finishes in December is a success. The same five-week build finishing in February has missed most of what it was for, and no amount of quality recovers the difference — the parents made their decision while the old site was still up. When a school asks us in November whether there is time, the honest answer is sometimes no, and it is better said in November than in February.

It also changes what you build first. Load matters in a concentrated window, not on average: the site has to hold up on the evening a circular goes out and every parent opens it within the hour. That is a very different engineering target from steady traffic, and it is why the gallery pipeline and static delivery were settled early rather than left as optimisation for later.

If you are a principal or a trustee reading this before commissioning a site: the single highest-value question to ask any vendor is not about design. It is “what date will this be live, and is that before or after our admissions open?”

Measured

What it carries

Gallery
~400 images, AVIF and WebP at build time
Documents
About a dozen downloadable files
Enquiries
Low tens per day
Peak
January to March admissions
Build
5 weeks, discovery to live

finish before the season, not during it

What we got wrongwe rebuilt it after watching

The first editing screen assumed too much comfort.

The first editing interface assumed too much comfort with forms — we rebuilt it plainer after watching the office actually use it.

The first version was a perfectly ordinary admin form. Labelled fields, sensible grouping, validation messages, a save button — the kind of screen every developer has built a hundred times and can use without thinking. That last part is the trap. We can use it without thinking because we have used a thousand of them.

The person actually updating the fee table has not. Sitting with the office made the failures obvious within twenty minutes: uncertainty about whether a change was live or merely saved, hesitation over fields whose labels made sense to us and not to them, and a reluctance to press anything twice in case it did something twice. None of that shows up in testing, because the developer testing it already knows what every control does.

We rebuilt it plainer — fewer fields on screen, unambiguous language about what is published and what is not, and confirmation that says what happened in words rather than a green tick. The general lesson is one we now build into the schedule rather than discovering: an internal screen is not finished when it works, it is finished when the person whose job it is can use it without rehearsal. Half a day of watching someone use it is worth more than a week of our own review, and it belongs in the plan from the start.

If you run a schoolwhat we would ask you first

Four questions before anyone quotes.

When do admissions open

Work backwards from that date. It decides whether the project is worth starting this year or should be planned properly for the next cycle.

Do the photographs exist

Real campus photography is the largest single factor in whether a school site persuades anyone, and arranging it takes longer than building the gallery.

Who answers an enquiry

Name the person. The system should deliver enquiries where they already look, not create a place they must remember to check.

What must staff edit alone

Usually fee tables, dates and circulars. Agree the list up front — it is the boundary between an editable page and a fixed structure.

If the pressure in your week is fee collection rather than admissions, the website is the wrong project — start with fee management software for small schools instead, and see how we cost a build for what moves the number either way.

Admissions season is
closer than it looks.

Tell us your intake dates and what your current site does badly. If there is not enough time to do it properly this cycle, we will say so.

no commitment required · we reply within 24 hours