School student portal development for an institution that wants one front door.
For school and university IT leaders whose learners, parents, teachers, and staff keep crossing between disconnected systems, we build the portal around the institution.
Buyers who need the platform to fit their operation.
K-12 schools and multi-school districts
Institutions needing one front door for students, parents, and teachers, where the SIS, LMS, and communication tools currently live in separate logins.
Higher-ed institutions and universities
Colleges with LMS, SIS, registration, and finance in disconnected products, and a growing need for one portal experience per role.
Independent and private schools
Schools with specific pedagogical models and communication expectations that a generic vendor portal cannot accommodate without compromises.
International schools and networks
Multi-campus institutions that need consistent access, permissions, and reporting across sites while respecting local variations in curriculum and language.
Problems we solve
The specific work your current platform leaves behind.
Students, parents, and teachers manage five logins for one school.
One portal that unifies sign-in, timetable, assignments, grades, messages, and administrative tasks across the systems your institution already runs.
SIS is the source of truth but nothing else knows.
SIS integration (PowerSchool, Infinite Campus, SchoolLogic, Ellucian, and custom) with enrolment, class membership, and guardian relationships propagated to the portal automatically.
Parent access is a compliance problem waiting to happen.
Guardian relationships modelled as first-class access rules: correct child visibility, sibling grouping, custody-aware permissions, and an audit log of every view.
Gradebook lives in one product; the LMS lives in another.
Teacher-facing gradebook integrated with the LMS and SIS, so an assessment moves cleanly from submission to grade to student record without a manual export.
Legacy accounts, roles, and course data are blocking a move.
Staged migration with SIS as the source of truth, dry-run validation, and a rollback plan so the switch happens without losing a term's worth of records.
Every new tool means another security review.
Portal designed for student-data compliance (FERPA, GDPR where applicable) with access rules, retention, and audit built into the data model rather than added at the end.
Capabilities
What we build inside school portal development.
01
SIS Integration
PowerSchool, Infinite Campus, Ellucian, SchoolLogic, and custom SIS integration for enrolment, class membership, timetables, and guardian relationships. Sync validated before every rollout so a bad import does not reach production.
02
Parent Portal
Guardian-scoped views of children (including siblings and split-custody cases), messages, attendance, grades, and school communications, with an access log administrators can inspect when needed.
03
Teacher Dashboard
Class rosters, attendance, assignment submission and feedback, gradebook, and communication tools that respect class-level permissions instead of showing every teacher every student.
04
Student Dashboard
Timetable, assignments, submissions, grades, messages, and resources in one place, with role-appropriate visibility and a clear next action rather than an institutional sitemap.
05
SSO
SAML and OIDC integration with Google Workspace for Education, Microsoft Entra ID, Clever, ClassLink, and custom IdPs. OneRoster rostering supported where the SIS provides it.
06
Permissions
Role, class, cohort, and guardian-relationship permissions modelled in the data layer. Access decisions are enforced by the API, not just hidden in the UI, so a direct request cannot bypass what a screen hides.
07
Reporting
Role-scoped reporting for teachers, department heads, administrators, and district leaders, with scheduled exports and pre-built queries for the questions inspection and accreditation actually ask.
How projects work
From first call to handover.
01
Week 1: walk a real school day
Trace a student, guardian, teacher, and admin task through current systems. Handoffs reveal what the portal must unify and what it should leave alone.
02
Weeks 2 to 3: set the source of truth
Which system owns identity, enrolment, grades, and learning data. Unglamorous but essential: prevents the portal from creating a second, unreliable version of school records.
03
Weekly builds: pilot with real roles
A small group of students, teachers, and parents test the priority flows. Their confusion is useful, and far cheaper than a full-term rollout followed by a support backlog.
04
Launch: governance and cutover
Documented access, support, and change-approval paths. Data migration validated, staff runbooks written, and code plus infrastructure handed over with continued support available.
SSO integration (SAML, OIDC, OneRoster where available)
Parent, teacher, student, and admin portals
Gradebook and assignment integration
Messaging and school-communication flows
Migration plan for legacy accounts and course data
Role-scoped reporting and scheduled exports
Security review aligned with student-data expectations
Automated test suite and CI pipeline
Deployment infrastructure and runbooks
Full source code and technical documentation
Governance and operations handover
Budget and tradeoffs
What moves the price
The cost of a school portal changes sharply with SIS integration, the number of roles the portal serves, parent access, gradebook requirements, legacy data migration, and whether the portal also replaces an LMS or sits alongside it. We recommend beginning with the student service that causes the most friction, then expanding from a stable base, and quoting against that specific first release rather than a generic range.
We scope in the open. You see the assumptions, what is excluded, and what would change the estimate. A fixed price without those details is only a delayed surprise.
FERPA
the U.S. law governing who may see a student's education records. A portal has to enforce that in its permission model, by design, not by asking staff to remember a policy. Get the guardian-relationship rules wrong and you have a compliance problem, not a bug.
The platform should make the next decision easier.
Students get a clearer path through school life. Teachers and staff spend less time translating between systems. The institution gains a portal it can shape around its own policies instead of asking every department to adapt to a generic product.
SIS integration, the number of roles, parent access, gradebook needs, and legacy data migration move the number the most. We usually start with the student service causing the most friction, then expand from a stable base, and quote against that specific first release rather than a generic range.
How long does it take to launch?
About 8 to 12 weeks for a focused first release. The high-volume paths, sign-in, timetable, assignments, get built and validated first.
Who owns and protects the student data?
Your institution controls the environment and the data-access model. We design permissions, audit needs, retention, and incident responsibilities with you, and document them before launch rather than after.
Do we have to replace our SIS and LMS?
No, and replacing everything is often the riskiest first move. The SIS can stay the source of truth for enrolment and the LMS can keep course content, while the portal gives students, parents, and staff one front door through tested integrations.
Bring the awkward part of the current setup.
We will map the real constraint, tell you whether a custom build makes sense, and outline a first release that does not pretend to solve every future problem.