Software Development for School Districts & Public Higher Education
Software Development for School Districts and Colleges
Integration, portals, and legacy modernization for districts and colleges, built around student privacy, accessibility, and the academic calendar.
Almost no district or college writes its own student system. The software that matters is bought: a student information system, a learning management system, a finance and human resources platform, an assessment vendor, a payment processor. Development work in education lives in the space between those products, and that space is wider than in most of government. Every instructional application a teacher or a department adopts needs a roster. Every roster is a disclosure of student data to a third party. Every disclosure has to be defensible under FERPA, under a state student privacy statute, and under a data agreement someone signed, often years ago, that nobody has re-read since.
The second constraint is the calendar. A district or a college cannot move a go-live because a sprint slipped. Enrollment opens when it opens, terms roll over on a fixed date, state reporting windows close, and a bad release in the first week of school is felt by every family at once. Teams sized for classroom and help desk support are expected to absorb that work alongside a device fleet, and in higher education the same pressure is spread across departments that each buy and build on their own.
What these environments look like
- A student information system as the source of truth for enrollment, scheduling, attendance, and grades, feeding nearly every downstream platform
- A learning management system plus a long list of instructional and assessment applications, many adopted at the site or department level, each needing rostering and single sign-on
- Vendor student and finance platforms in colleges carrying years of local customization that has to be reviewed and re-applied at every upgrade
- Homegrown applications, often a database or a small web application written by one staff member, running a real process with no documentation and no source control
- Family-facing processes still on paper or fillable PDF: enrollment packets, meal benefit applications, transportation requests, permission forms, and fee payment, each with a separate login if it is online at all
- State reporting interfaces with fixed submission calendars and strict validation rules
- Student data governed by FERPA and by state student privacy statutes that vary considerably, with financial aid records in higher education carrying additional federal safeguards obligations
Where HQT helps
- Integration between the student information system and downstream platforms through documented APIs and education data standards such as OneRoster, Ed-Fi, and LTI where the platforms support them, with each interface scoped to the minimum student data the receiving platform needs
- Monitoring on those interfaces, so that a failed roster sync is noticed by staff rather than by a teacher with a class that cannot log in
- Family and student portals that consolidate applications, forms, payments, and status into one place, built for a phone, designed for translation, and tested against WCAG 2.1 Level AA
- Replacement of paper and PDF workflows with tracked, auditable applications, frequently on a low-code platform the district or college already licenses, with enough governance that the result does not become the next undocumented system
- Modernization of homegrown applications, starting with extracting and documenting the business rules inside them, then moving functions across incrementally rather than in a single cutover
- Accessibility work on existing sites, applications, and document libraries, including automated checks in the build pipeline and manual testing with assistive technology, since automated scanning alone does not establish conformance
- Agile and DevSecOps delivery with environments that mirror term rollover, a release plan built around the academic calendar, and application support with service levels that recognize when the pressure actually falls: registration, the opening weeks of a term, and reporting windows
How an engagement usually starts
Work of this kind usually begins with a specific break rather than a strategy. A student information system migration is underway and the integrations built around the old one will not survive it. A staff member who wrote an application the registrar depends on is retiring. An accessibility complaint arrives, or counsel reads the federal rule that applies WCAG 2.1 Level AA to the web content and mobile applications of state and local government entities, with compliance dates that depend on the size of the entity, and asks what the plan is. A cabinet member tries to complete an enrollment form on a phone and gives up.
The first step is a short discovery: what the system actually does, what data moves through it, who depends on it, and what the agreement with each vendor allows. That produces an inventory of integrations and data flows, a scoped fixed-price proposal, and a sequence that fits the calendar, with the first increment timed so that people can see it working before the next term begins. HQT delivers code and documentation into the institution's own repositories, so that the district or college can maintain, rebid, or replace the work without depending on the team that built it.