A school website is not just a marketing asset. It is a publishing system, an admissions channel, a parent-service hub, and often a compliance surface all at once.
If you are an admissions lead, IT manager, bursar, or principal comparing website options for a school, you are usually balancing three pressures at the same time: the site must look credible to prospective families, it must be easy for staff to maintain, and it must not expose the institution to avoidable accessibility or privacy problems. That combination is exactly why a school website cannot be evaluated like a typical business brochure site. A custom build is often considered when a school needs more than a homepage and a contact form: multiple audience journeys, secure data collection, structured content for departments, and integrations that reduce manual admin.
Prebo Digital’s web development and strategy work is shaped by performance and operational clarity, which matters here because schools rarely want a flashy redesign that creates more work for internal teams. They need a system that supports admissions, parent communication, events, staff updates, and policy publishing without turning every small change into a ticket. In practice, the real question is not “Should we rebuild?” but “Which development approach will reduce admin load, support compliance, and survive the next three to five years of school operations?”
Why school websites differ from business sites
A business site usually serves one primary commercial journey. A school website serves several audiences with different urgency levels and different permissions. Parents want term dates, fees, forms, and contact points. Students want timetables, LMS access, news, and resources. Prospective families want admissions information and proof of quality. Staff need document publishing tools and role-based access. Governing bodies and administrators need accurate records, policy pages, and controlled editing workflows. That makes information architecture more important than visual polish alone.
Schools also carry stronger obligations around accessibility and privacy than many commercial sites. The site may host downloadable policies, application forms, event booking pages, and portals that collect student or parent data. A small mistake, such as a form that is not keyboard accessible or a document that is posted without readable structure, can affect both usability and compliance. A custom site lets the school design around those realities instead of forcing them into a generic template.
If your website is used by multiple departments, your biggest risk is not the homepage design. It is fragmented content ownership, weak permissions, and forms that collect data without a clear workflow.
Custom vs template vs DIY builder: which model fits a school?
The right choice depends on budget, governance, and how many functions the site must support. A template site can be perfectly adequate for a small school that mainly needs a polished online presence. A DIY builder can work for a very small institution with minimal integrations and an internal champion who is comfortable updating pages. A custom build becomes more compelling when the site must connect to admissions systems, LMS platforms, calendars, payment flows, and multilingual or multi-campus content structures.
| Option | Best fit | Strengths | Trade-offs |
|---|---|---|---|
| DIY builder | Small schools with limited content and low integration needs | Fast to launch, low upfront cost, simple editing | Limited flexibility, weaker governance, harder to scale |
| Template-based site | Schools needing a professional site with moderate complexity | Faster than custom, better branding control than DIY | Can become restrictive when workflows and integrations grow |
| Custom development | Schools with multiple audiences, portals, and compliance requirements | Tailored workflows, better integration planning, stronger long-term fit | Higher upfront cost and more planning required |
For most growing schools, the tipping point is not appearance. It is workflow complexity. If staff are manually updating calendars in one place, admissions forms in another, and parent notices by email because the CMS cannot support structured publishing, the site is already costing time. Custom development pays for itself operationally when it reduces duplication and centralises those tasks.
Must-have features by school type
The features a school needs should be mapped to its operating model, not copied from a competitor. K-12 schools usually need strong parent communication, safeguarding-friendly content architecture, event calendars, and quick access to policies and classroom information. Colleges and universities usually need department structures, faculty directories, programme pages, research content, and more complex admissions journeys. Districts and multi-campus groups often need central governance with local site autonomy.
| School type | Priority features | Why they matter |
|---|---|---|
| K-12 school | Admissions forms, noticeboard, events calendar, parent login links, staff directory | Reduces admin queries and makes day-to-day updates easier |
| College or university | Course finder, faculty profiles, application workflows, news hub, document library | Supports recruitment, credibility, and content discoverability |
| District or group | Multi-site governance, shared templates, permissions, branch pages, content approval | Keeps branding consistent while allowing local relevance |
A useful rule is to design the top navigation around the three jobs people most often arrive to do: apply, find information, and contact the right person. Anything that slows those journeys creates unnecessary calls to reception and admissions teams. On the editorial side, content blocks for policies, term dates, and announcements should be modular so staff can update them without breaking page structure.
Understanding compliance and accessibility: FERPA, COPPA, WCAG, and ADA
Compliance is not a legal checkbox that gets added at the end. It should shape the design brief from the beginning. In the United States context, FERPA governs the privacy of student education records, while COPPA affects the collection of information from children under 13. Accessibility obligations under WCAG and, in many cases, ADA-aligned practice mean the site must be usable by people with disabilities, including keyboard-only users and screen reader users. For institutions with international enrolment or EU-facing operations, GDPR considerations may also matter if personal data is collected from applicable users.
A good custom build accounts for these requirements through content structure, form design, media treatment, and permissioning. For example, downloadable PDFs should not be the only place critical information exists. Forms should include clear labels, error messaging, and logical tab order. Video and image content should include alternatives where relevant. Cookie and consent practices should be reviewed with the institution’s legal or compliance adviser, especially if tracking is used for marketing or analytics.
WCAG conformance is easier to sustain when accessibility is built into the CMS templates, not handled page by page after launch.
For practical planning, a school should treat accessibility review as a design deliverable, not a post-launch audit only. That includes contrast checks, heading structure, form labels, focus states, keyboard navigation, and testing with assistive technologies. If the school publishes admissions or parent-facing content in multiple languages, the translation process also needs governance so that accessibility is not lost in copy swaps or pasted text from documents.
Essential integrations: SIS, LMS, payment systems, and calendars
A custom school website becomes far more useful when it connects to the systems the institution already uses. Typical integrations include a student information system, an LMS such as Canvas or Google Classroom, online payment processors for fees and events, and shared calendars for academic dates and notices. The goal is not to connect everything for its own sake. It is to reduce duplicate data entry and give users a single front door to important functions.
The right integration plan depends on data sensitivity and how often information changes. Calendar feeds and public notices are straightforward. Admissions forms and portal logins are more sensitive and should be planned with secure data flows and clear ownership of each field. Where a school already has an SIS, the website should ideally pull stable data from that system rather than asking staff to maintain duplicate records. That approach reduces errors, especially for timetables, term dates, and contact directories.
If your current website is forcing staff to retype the same information into the CMS, SIS, and email system, you have an integration problem, not a content problem.
Cost and timeline breakdown: what to expect
School website budgets vary widely because scope matters more than industry label. A smaller institution with a straightforward brochure site and standard CMS setup may require a modest build, while a multi-campus group with portals, permissions, and data integrations will need a larger investment. In South Africa and comparable markets, a realistic custom project often falls into one of three planning bands: a foundational build for a simpler website, a mid-range build for more content and integrations, or a more complex build for multi-site governance and bespoke workflows. These should be treated as estimates, not fixed prices.
| Project scope | Typical timeline | Main cost drivers |
|---|---|---|
| Foundational site | 6 to 10 weeks | Number of page templates, content migration, design approvals |
| Mid-complexity build | 10 to 16 weeks | Integrations, accessibility work, stakeholder review rounds |
| Complex multi-site platform | 16+ weeks | Governance, custom modules, security review, content migration scale |
Cost is driven by discovery depth, design complexity, integrations, accessibility remediation, and the amount of content migration required. Schools often underestimate how much time is needed to restructure old pages, clean outdated PDFs, and assign ownership for ongoing updates. The cheapest project on paper can become the most expensive if it creates a maintenance burden for years.
Vendor selection and RFP checklist
A strong vendor should be able to explain not only how they will build the site, but how the school will govern it after launch. In an RFP, ask for the proposed CMS, accessibility approach, migration plan, testing process, hosting model, and support arrangement. You should also require clarity on which team members will train staff, how change requests are handled, and what is included in post-launch support. A polished pitch deck is not enough; schools need operational detail.
A vendor that cannot describe content ownership, approval workflows, and rollback procedures is not ready for a school environment with shared responsibility.
Your selection committee should usually include an IT lead, an admissions or communications representative, a senior school leader, and someone who manages day-to-day content publishing. If the website will support online payments or portals, include finance or operations. Their combined view helps prevent a build that looks impressive but fails the practical test of daily use.
- Ask how accessibility is tested before launch and after updates.
- Request a content migration plan that identifies stale pages and duplicate files.
- Confirm who owns hosting, backups, and incident response.
- Require a training plan for non-technical staff.
