Development Agency
Contact Sign in Get a project quote

Service

School website development

For heads, bursars and school office managers who need a website and parent-communication system designed around how their school actually handles admissions, the calendar, policies, clubs and trips, rather than a brochure template with a contact form.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

Most school websites were built for prospective parents and then quietly became the place where everything else was dumped.

  • The term dates live in a PDF that the office updates once a year and forgets about when an inset day moves.
  • Policies sit in a downloads page with no review date, so the safeguarding policy that was revised in September is still showing the previous version in January.
  • Open-day bookings arrive by email, are copied into a spreadsheet by the admissions secretary and confirmed by hand, and two families booking the last two places at the same moment both get a yes.

Where it gets harder

Clubs and trips are where the paper really piles up.

  • A letter goes home in the book bag, a consent slip comes back three weeks later with a cheque or a cash envelope, and the trip leader keeps a tally on a printed list that is out of date by the time the coach is booked.
  • Parents ask the office whether their child is on the list; the office rings the trip leader.
  • Vacancies are posted on a jobs board and never taken down.
  • The communications lead maintains a newsletter in one tool, notices in another and the website in a third, and none of them knows which parents belong to which year group.

Scope of the service

What the build covers

A custom school build normally covers the public site and the parent-facing workflows behind it: an admissions enquiry form that routes to the right person by year group and entry point, open-day events with capacity and booking, term dates and a school calendar that feeds the site, parent notices and the newsletter from one place, a staff directory and department pages maintained by the departments themselves, a policies library with owner and review date on every document, clubs and trips with sign-up, consent capture and payment, vacancy listings with closing dates, and an optional secure parent portal where notices, letters and consent forms live against the family rather than the book bag.

How discovery works

We begin by following the school year with the office: the admissions round, the September rush of club sign-ups, a residential trip from first letter to coach departure, and a policy review cycle. Each becomes a named workflow stage in the scope document.

  1. Enquiry
  2. Open day
  3. Application
  4. Parent portal onboarding
  5. Clubs and trips sign-up and consent
  6. Payment
  7. And policy publication with review reminders

Deliberately out of scope

  • The management information system itself, with its pupil records, assessment and attendance. That remains the school's existing system, and we connect to it for class lists and parent contacts where the connection is available and the school wants it. Payroll, finance beyond collecting club and trip payments, and timetabling also stay where they are

When the scope grows

Scoping scenario

A two-site prep and senior school wants one website with a shared calendar, admissions enquiries routed differently for each entry point, trips that require consent from one named guardian only, and a parent portal that shows a family with children at both sites everything in one login. The cross-site family view and the guardian rules are what make it a custom project.

Deliverables

What you receive

  • Discovery notes from following a school year with the office, the admissions secretary and a trip leader
  • A scope document naming each stage, the access rules around parent and pupil data and what is out of scope
  • Design of the public site, the calendar, the trip sign-up flow and the parent portal on phones first
  • The build, deployed to your hosting or ours, with role permissions and an audit of who published what
  • Migration of policies, term dates, staff pages and news from the current site, where relevant
  • Training for the office, the communications lead and department editors, with a written guide per role
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current website, the management information system export, the policies folder and any newsletter tool, with a named contact in the school office.

    Project stage: Onboarding

  2. Planning

    Walk-throughs of the admissions round, a residential trip and a policy review with the people who run them; the scope document and milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the home page, the calendar, the trip consent flow and the portal notice list, reviewed on the phones parents actually use.

    Project stage: Design

  4. Development

    Built in stages: public site and calendar first, then admissions and open days, then policies, then clubs and trips with consent and payment, then the parent portal.

    Project stage: Development

  5. Client review

    The office runs a mock admissions round and a mock trip on test families, and department editors publish real pages for review.

    Project stage: Client review

  6. Revisions

    Changes from the review, particularly to consent wording, routing and the portal, are made and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Content migrated, redirects from old URLs in place, parent accounts invited in a staged way, launch timed away from the admissions deadline.

    Project stage: Ready for launch

  8. Delivered

    The school runs on the new site; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Management information systems for class lists, year groups and parent contact details
  • Card payment providers for club, trip and uniform payments
  • Email and SMS providers for notices, reminders and emergency messages
  • Calendar feeds so term dates and events appear in parents' own calendars
  • Online admissions and application platforms the school already uses
  • Document storage where policies are authored before publication

How we would approach it

Worked example

Concept demo

A two-site school with one parent login

In this scoping scenario, a prep and senior school on separate sites wanted a single website, a shared calendar filtered by site and year group, and a parent portal where a family with a child at each site sees both children's notices, trips and consent requests in one place. Admissions enquiries needed to route to a different registrar per entry point, and residential trips needed consent from a named guardian with a medical form attached before the place was confirmed.

The scope we would propose: a family record holding guardians and children across sites with per-guardian permissions, a calendar with site and year-group tags, routed enquiry forms, and a trip workflow where the place is held until consent and payment are both recorded. The reason this is a custom build rather than a template is the family model: most school website products assume one site and one parent per child, which is the assumption this school needed to break.

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of sites, phases and year groups the calendar and routing must distinguish
  • Whether the parent portal is in scope and how guardians and families are modelled
  • Clubs and trips with consent and payment, and the payment provider involved
  • Connection to the management information system and what it can export
  • Volume of policies, news and staff pages to migrate from the current site
  • Number of department editors and the approval steps before publication
  • Admissions enquiry routing and open-day capacity rules
  • Hosting choice: your own hosting or ours

Start from a package

School website package

Public website, term calendar, policies library, admissions and open-day booking, clubs and trips with consent and payment, and an optional parent portal for schools and nurseries.

Custom build
View the package

FAQ

Frequently asked questions

When do we need a custom build rather than the package?

When the family model, routing or consent rules break the assumptions of the school website package. During discovery we lay your admissions round and a trip against the package and say plainly whether configuration covers them or whether, for example, your multi-site families need custom work.

How is parent and pupil data protected in the build?

Access is role-based: a parent sees only their own children, a trip leader sees only their trip, and the office sees what its role allows. Every view and change of a family record is logged. The school remains responsible for its own data protection arrangements; the build gives you the controls and the records to operate them.

Can it connect to our management information system?

Where the system offers an export or an interface, we assess it during discovery and state in the scope document what can be read from it, typically class lists and parent contacts. Nothing is promised as a ready connection until it has been assessed.

Who maintains the content after launch?

Your office and department editors. The build gives each editor rights over their own pages and the communications lead an approval step where you want one. Training and a written guide per role are part of the delivery.

Who owns the website afterwards?

The school does. Source code and data are handed over at delivery; hosting and maintenance are optional, separately agreed and movable to another provider.

Get a project quote for school software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences