Educational Software

Software built for how your institution actually teaches.

Education is the sector we've worked in longest, and business schools are where the standard platforms fit worst.

Executive education runs six intakes a year on rolling dates. Blended programmes mix delivery modes inside one course. Consortium degrees split a student across two registries. We build the parts a configuration screen can't reach.

Email us
Where we start

The registrar knows where it hurts

Before anyone writes code we sit with the people running the process. Programme administrators, the academic office, the assessment team. They'll tell you in ten minutes which four steps of an eight step workflow happen in a spreadsheet, and why.

Roughly half of what comes out of that turns out to be a configuration change or a report rather than a build. We say so before quoting.

Building a page layout in a visual editor

What we build

Common shapes of work. Yours will differ in the details, which is the point.

Assessment and grading

Multi-marker moderation, group assessment, penalty rules, appeals. The logic your academic policy specifies and your platform approximates.

Student and cohort portals

One place for a student to see progress, deadlines and results across programmes living in three different systems.

Admissions and application review

Scoring rubrics, panel review, interview scheduling and offer generation for programmes with non standard entry.

Timetabling and calendars

Rolling intakes, intensive blocks, residential weeks and cross campus scheduling that a semester grid can't express.

Faculty workload

Teaching load, moderation duty and supervision tracked against the agreement your faculty actually signed.

Alumni and executive education

Lifecycle tracking after graduation, where the CRM you own was designed for degree students and stops at conferral.

Buy, configure, or build

Three options, and the order matters. Buying is cheapest when a product fits. Configuring is next. Building is last, and it earns its cost only when the process is something you compete on, or when nobody sells the thing at all.

We'll tell you which applies before we quote a build. That costs us work sometimes. It's still the right way round.

What people ask about custom builds

Mostly about risk, and reasonably so.

  • Will this replace our student information system?

    Almost never. The SIS stays the system of record. We build alongside it and write back through its interfaces, so your registry team keeps working as they do now.

  • What about accessibility?

    Anything student facing gets built to WCAG 2.1 AA and tested with a keyboard and a screen reader before release. Institutions get asked about this in procurement and in complaints, so we treat it as a requirement rather than a phase at the end.

  • Who owns the code?

    You do. It sits in your repository and your cloud accounts from the first commit. No licence, nothing rented back from us.

  • What happens when we want to change it in two years?

    You change it, or you ask us. Both are meant to work. We hand over documentation and runbooks, and keep the stack deliberately ordinary so your next team doesn't need us in the room to read it.