EdTech Platform Development: Lessons from Building for UK Universities

Education technology is one of the more demanding domains in software development. The user groups are diverse — students, academics, administrators, external stakeholders — and their technical capabilities and expectations vary enormously. The data is sensitive and regulated. And the organisations commissioning the software often operate on academic procurement timelines that are longer than commercial projects.

We've delivered EdTech projects for UK universities, colleges, and private learning platforms over 15 years. This article covers the distinctive challenges of education software and the lessons we've learned the hard way.

What Makes EdTech Different

Education software has characteristics that distinguish it from most other software categories:

• Extreme user diversity: the same system is used by 18-year-old students and 65-year-old professors, with widely varying digital literacy
• Seasonal load patterns: a university admissions system gets 10x normal traffic during Clearing; an exam platform spikes during exam season
• Long institutional memory: universities often have data going back decades that new systems must accommodate or migrate
• Complex governance: changes to student-facing systems typically require approval from academic boards, IT committees, and data protection officers
• Accessibility requirements: WCAG 2.1 AA is increasingly mandated for UK higher education institutions
• Regulatory environment: GDPR applies with particular force to student data; some institutions also follow FERPA or sector-specific guidance

Case Study: LSHTM Admissions System

Our most referenced EdTech project is the admissions management system we built for the London School of Hygiene & Tropical Medicine. It's a useful case study because it illustrates many of the challenges and solutions that apply broadly to UK higher education software.

The problem: LSHTM's admissions team was managing hundreds of applications per cycle using a combination of SITS (Student Information System), Excel spreadsheets, email, and manual chasing processes. The result was 25+ hours per week of administrative work, high error rates, and a frustrating experience for both applicants and staff.

The solution: a purpose-built admissions workflow tool that integrated with SITS, automated status communications to applicants, created a unified view of each application's progress, and provided management reporting dashboards.

The outcome: 75% reduction in administrative processing time, near-elimination of data entry errors, and significant improvement in applicant satisfaction scores.

Architecture Considerations for University Software

Integration with Legacy Systems

UK universities typically run SITS (Tribal), Banner, or increasingly Ellucian as their Student Information System. These are mature, complex systems with extensive APIs and integration patterns that vary significantly between institutions.

Our recommendation: treat the SIS as a source of truth for student records, but don't try to replace it or run everything through it. Build your application to integrate via API, sync data on a schedule, and maintain a local cache for performance. Direct database access to SIS tables is almost always a mistake — it breaks with upgrades and bypasses the system's business logic.

Most UK universities have also accumulated 20+ years of institutional data in varying formats. Any project that requires migrating or connecting to this data needs a realistic data quality assessment at the outset.

Authentication and Access Control

UK universities typically use Microsoft Azure AD or an on-premise Active Directory for identity management, with single sign-on provided via SAML 2.0 or OIDC.

Build for SAML/OIDC integration from day one — don't implement a separate username/password system. Students and staff will not adopt a system that requires them to remember another password, and the IT security team will not approve it.

Access control in university systems tends to be complex: a supervisor might see their own students but not other departments' students; an administrator might see all records but not edit them; an applicant sees only their own record. Model this carefully in the data architecture rather than implementing it as UI constraints.

Handling Seasonal Load

University application platforms experience extreme traffic seasonality. UCAS clearing typically generates 10–20x normal traffic in a 72-hour window. Exam portals see complete inactivity for weeks followed by near-simultaneous access from thousands of students.

Auto-scaling cloud infrastructure is essential — don't size your servers for peak load and pay for that capacity year-round. Use AWS Auto Scaling Groups or equivalent, pre-warm capacity for known peak events, and load test thoroughly before clearing or exam windows.

Also implement circuit breakers and graceful degradation: if the platform is under extreme load, what is the minimum viable experience that must remain available? Identify this upfront and ensure it's protected.

Accessibility: Not Optional

UK universities are legally required to ensure their digital services are accessible under the Public Sector Bodies Accessibility Regulations 2018. WCAG 2.1 AA is the standard.

In practice, accessibility in EdTech means:

• Full keyboard navigation (no functionality that requires a mouse)
• Screen reader compatibility tested with NVDA, JAWS, and VoiceOver
• Sufficient colour contrast (minimum 4.5:1 for normal text)
• Form labels and error messages that work with assistive technology
• Video content with captions and transcripts
• Documents (PDFs, Word files) that are accessible or have accessible alternatives

Accessibility should be built in from the design phase, not bolted on as a post-launch audit. Retrofitting accessibility is typically 3–5x more expensive than building it correctly the first time.

Student Data and GDPR

Student data is personal data under GDPR, and it often falls into special categories (health conditions, ethnicity, disability) that require additional protections.

Key requirements for UK university software:

• Lawful basis for processing must be established and documented for each data category
• Data retention periods must be defined and enforced — student records aren't kept forever
• Subject access requests: students can request all data held about them; your system must support this
• Data minimisation: only collect what you actually need for the stated purpose
• Privacy by design: encryption at rest, role-based access, and audit logging from the start

We recommend involving the institution's Data Protection Officer in requirements gathering for any project handling student data. It's more work upfront but prevents expensive retrofits later.

Managing the Procurement and Approval Process

University procurement operates differently from commercial procurement. Budgets are often confirmed annually, decisions require committee approval, and timelines for sign-off are measured in months rather than weeks.

Practical tips for working within this environment:

1. Start the IT security and data protection review as early as possible — these are the processes most likely to delay launch
2. Build in sufficient time for UAT by multiple stakeholder groups (students, academics, administrators all have different perspectives)
3. Expect change requests from each stakeholder group and scope this into your plan
4. Identify a senior internal sponsor who can unblock decisions when they get stuck in committee
5. Plan for a phased rollout — piloting with one faculty or cohort before full institutional deployment

The Learning Platform Landscape

A note on when not to build custom EdTech: the learning management system (LMS) market is mature. Moodle (open source), Canvas, Blackboard, and Brightspace serve the vast majority of UK higher education institutions well.

Custom development makes sense for: the workflow and administrative tools around learning (admissions, scheduling, project management, research systems), specialised assessment tools for specific disciplines, integrations between existing systems, and consumer-facing learning products where you need full design control.

It rarely makes sense to build a custom LMS unless you're in the business of selling it to other institutions.