Your School Website and Your Parent Portal Are Two Different Products

Two different products, one budget line

Ask a school administrator what they need and the answer is often "a new website." Ask a follow-up question — do parents need to check attendance, pay fees, or message a teacher through it? — and the real answer surfaces: they need two products, not one, and only one of them is a website.

A website is a public-facing marketing and information surface. Its job is to convert an interested parent or prospective student into an enrollment enquiry, and to answer the questions people ask before they call: programs offered, fees, admissions process, campus photos, contact details, term dates. Anyone can see it. Nobody needs to log in. Success is measured in enquiries and admissions, not in daily active users.

A portal is internal infrastructure with authentication behind it. Its job is to let specific, logged-in people do specific things: a parent checks their child's attendance and grades, a teacher submits marks, an administrator reconciles fee payments, a student downloads a transcript. Nobody outside the institution ever sees it. Success is measured in whether the front office still fields the same phone calls it fielded before the portal existed.

Treating these as one project — "the school website" — is where scope, budget, and security expectations all get tangled together, usually to the detriment of both halves.

Why bundling them backfires

When an institution briefs a single vendor for "a new website" and then adds portal-style features to the same brief mid-project, a few predictable things happen:

The public site inherits login complexity it doesn't need. A marketing site that exists to be found on Google and read by anonymous visitors gets built on the same authenticated framework as the portal, which makes it slower to load, harder to cache, and unnecessarily complicated to update for the office staff who just want to change a term date.

The portal inherits marketing-site assumptions it shouldn't have. A parent-facing grade book doesn't need a blog, an events calendar widget, or a CMS built for a marketing team to edit copy — but if it's bolted onto the same codebase as the website, it often ends up carrying that weight anyway.

Security review happens too late. A public website's worst-case failure is embarrassing. A portal's worst-case failure is a parent seeing another family's child's grades, or a payment record leaking. Those two products deserve very different levels of access-control scrutiny, and a single "build us a website" brief rarely prompts anyone to specify that up front — it gets discovered during (or after) a security incident instead of during scoping.

The budget conversation gets distorted. A marketing website is a comparatively contained, well-understood build. A portal with role-based access, integration with student records, and payment handling is a materially larger engineering effort — different data model, different compliance posture, different ongoing maintenance load. Quoting them as one line item makes the portal's real cost invisible until it's already being built.

How to actually scope the two

Start by separating the audiences, because the audience determines almost everything else:

• Public visitors (prospective parents, students researching options, the general public) → website. No login. Optimized for search visibility and fast information access.
• Enrolled families and staff (current parents, current students, teachers, administrators) → portal. Login required. Optimized for role-specific tasks: viewing grades, paying fees, submitting attendance, messaging staff.

Once separated, the two projects can be scoped independently, with a shared decision about how they connect:

1. Does the portal need to exist as custom software at all, or does it already exist? Many schools already run a student information system (SIS) or learning management system (LMS) that includes parent- and teacher-facing portal functionality out of the box. In that case, the actual work is a well-designed public website plus clean links or single-sign-on into the existing system — not a from-scratch portal build. Building a custom portal is worth it when the existing SIS/LMS genuinely doesn't cover a specific need (a fee-payment flow, a custom reporting view), not as a default.

2. What's the real user list for the portal, and what can each role do? Parent, student, teacher, department head, and admin office are usually not the same role with different labels — they see different data and need different permissions. Naming these roles before scoping avoids the single most common source of portal rework: discovering mid-build that "staff" needed to be three separate access levels.

3. What does the website actually need to do beyond "look good"? For most institutions, that's: rank for local search terms prospective families actually use, load fast on a parent's phone during a campus visit, and make the admissions inquiry form impossible to miss. That's a scoped, well-understood project — resist letting it expand to include things that are really portal features in disguise.

4. Who maintains each one, and how often? A website's content — term dates, staff bios, news — usually needs updating by office staff without a developer involved, which argues for a CMS built for non-technical editors. A portal's "content" is mostly data flowing in from other systems, which argues for integration reliability over editability.

What this looks like in practice

A mid-sized school evaluating this decision typically lands in one of three places: a marketing website only, with parents and staff continuing to use whatever SIS/LMS the school already licenses; a marketing website plus a thin custom portal for the one or two things the existing system doesn't handle well (often fee payment or a specific reporting need); or, less commonly, a full custom portal because the institution's needs have genuinely outgrown off-the-shelf school software. The first two cover the overwhelming majority of cases. The third is a real project with a real budget, and it should be treated as one from the first conversation, not discovered halfway through what started as a website brief.

Takeaway: Before requesting a quote, split "our website" into its two real products — a public site with no login, and an authenticated portal with role-based access — and check whether the portal half is already covered by your existing school management system. Most institutions need a good website and a link into software they already pay for, not a from-scratch portal.