Industry
Software engineering for Education
An educational institution is a regulated organisation before it is a place of learning, and its software has to carry statutory duties that carry legal weight: census returns to the DfE, safeguarding under KCSIE, accessibility under the public-sector regulations, and a student record that has to be right. Most edtech ignores how much of a school or college’s software life is compliance and administration, not pedagogy. We build for the institution and its obligations, around the MIS it already depends on, not for the demo.
Why the domain matters
An educational institution, whether a primary or secondary school, a sixth-form or further-education college, a multi-academy trust or a university, runs on administration far more than most edtech pitches acknowledge. Behind the teaching there is a student record that has to be accurate and lawful, admissions and enrolment that have to be fair and auditable, a timetable that has to reconcile rooms, staff and cohorts, assessment and reporting that feed real decisions, safeguarding that carries genuine legal and moral weight, and a set of statutory data returns to the Department for Education that are non-negotiable and time-bound. Software for this sector succeeds or fails on how well it serves those obligations, not on how attractive the learning interface looks. That is the opportunity and the discipline in one sentence.
The centre of gravity for a school or college is the management information system: the MIS, the system of record for pupils, staff, attendance, assessment and the data that feeds the census. Universities run the equivalent as a student information system, or SIS, alongside a virtual learning environment and a tangle of departmental systems. Whatever custom software you build almost always lives around that record rather than replacing it, because the MIS or SIS is where the statutory obligations are anchored and where the institution’s trust already sits. The recurring engineering reality in education is integration and data correctness against an incumbent system that is not going anywhere, under a term-time rhythm that leaves little room for a system that is unavailable during enrolment week or on census day.
We are a senior-led team and we operate what we build, so we start from how the institution actually discharges its duties rather than from a product we would like to sell. The failure mode in education software is the shiny tool that ignores the statutory and administrative reality: that will not reconcile with the MIS, that treats safeguarding as a form rather than a duty, that assumes a school has time and staff it does not have. We would rather build the unglamorous integration, the accurate record and the return that files cleanly than the pretty dashboard that impresses a governor and then fights the census. Course delivery, content and the learning experience are a different problem, and we treat them as such. This is about the institution and what it is legally and operationally on the hook for.
The challenges in education
The MIS or SIS is the system of record, and it stays
A school’s MIS or a university’s SIS is where pupils, staff, attendance and assessment actually live, and it feeds the statutory returns. Custom software almost always has to integrate with it (read from it, write to it, stay consistent with it), rather than replace it, because it holds the institution’s obligations and its trust. Any plan that assumes a clean greenfield or a rip-and-replace ignores the system the institution depends on every single day, and underestimating that integration is the most common way an education project ships late and half-working.
Statutory data returns that are time-bound and non-negotiable
The DfE school census, and the wider set of statutory returns, are fixed points in the year with defined data specifications and hard deadlines. The data has to be complete, correctly coded and reconciled against the MIS, and a return that is wrong or late is a real problem for the institution, not a cosmetic one. Software that touches this has to respect the specification exactly and make the data defensible. The compliance is in the accuracy of the record, not in a policy document beside it.
Safeguarding is a legal and moral duty, not a feature
Keeping Children Safe in Education places real obligations on schools and colleges around recording concerns, restricting access to sensitive information, and retaining records appropriately. Any system that touches safeguarding has to treat it with the seriousness it demands (tightly controlled access, a reliable audit trail, careful retention), because this is among the most sensitive data an institution holds and the consequences of getting it wrong are measured in harm to children, not just in a defect ticket.
A term-time rhythm with no slack at the wrong moments
Schools, colleges and universities run to a calendar with brutal peaks, enrolment and induction, exam periods, results days, census day, admissions cycles. A system that is slow or unavailable during enrolment week or when the census is due does damage that a quieter time of year would absorb. Building for education means building for those peaks specifically, and planning changes and migrations around a calendar that will not move for your release schedule.
Accessibility is a legal requirement, not a nicety
As public-sector bodies, most schools, colleges and universities are bound by the accessibility regulations, which require their websites and digital services to meet a recognised standard and to publish an accessibility statement. For anything student- or parent-facing, accessibility is a legal obligation and a genuine inclusion issue (learners and families have a right to use these services), so it has to be engineered in from the start rather than retrofitted after an audit flags it.
Fragmented systems, tight budgets and stretched staff
An institution rarely runs one system; it runs an MIS, a finance system, a VLE, admissions tools, assessment platforms and departmental spreadsheets that rarely agree. Budgets are constrained and administrative staff are stretched, so software that adds data entry, demands a specialist to run, or creates yet another disconnected island tends to fail. The value is in reducing administrative load and reconciling the systems that already exist, not in adding another one that needs feeding.
What we build for education
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
MIS and SIS integration layers
Integration between the institution’s system of record and the tools around it, reading pupil, staff, attendance and assessment data, writing back where appropriate, and keeping everything consistent so nothing is entered twice. We treat this as the core of most education work, building resilient connections to the MIS or SIS rather than pretending the institution will move off a system that holds its statutory obligations and its trust.
Admissions and enrolment systems
Applications, offers, enrolment and induction handled as an auditable, fair process, capturing the right data, tracking each applicant through the cycle, and reconciling with the record system so an enrolled student exists once and correctly. Built for the admissions peak specifically, because this is one of the calendar points where an unavailable or inconsistent system does real, visible damage to the institution and to families.
Timetabling and scheduling tools
Scheduling that reconciles the genuinely hard constraints (rooms, staff, cohorts, availability and clashes), into a timetable people can actually run. We are honest that timetabling is a constraint problem with real trade-offs rather than a solved one-click exercise, so we build tools that support the timetabler’s judgement and expose the conflicts clearly, not a black box that produces an infeasible grid nobody trusts.
Assessment, reporting and analytics
Assessment recording, progress tracking and reporting that turn the institution’s data into something staff, leaders and parents can act on, marks and grades captured consistently, progress made visible, and reports generated reliably at the points in the year they are needed. Built against the MIS as the source of truth so the analysis reflects the real record rather than a divergent copy that quietly drifts out of step.
Statutory returns and data-quality tooling
Tooling that helps an institution get its DfE census and other statutory returns right, validating data against the specification, surfacing gaps and coding errors before the deadline, and reconciling against the MIS so the return is complete and defensible. We build to the specification exactly and make the data quality visible in advance, because a return discovered to be wrong on deadline day is a genuine problem, not a cosmetic one.
Parent and student portals
Self-service portals that reduce administrative load, parents seeing attendance, reports, messages and consent, students accessing the information relevant to them, built to the accessibility standard the sector is legally held to and integrated with the record system behind them so information is shown once and stays consistent. Scoped to what families and students will genuinely use, so the portal takes work off the office rather than becoming another channel to monitor.
Where we help
A trust-wide layer over several schools’ MIS data
A multi-academy trust wants a consistent view across schools that each run their own MIS, without ripping any of them out. The real work is the integration: reading attendance, assessment and pupil data from each MIS, reconciling it into a coherent trust-level picture, and keeping it consistent as each school updates its own record. Done well, central teams get comparable data across the trust; done as a naive copy, the numbers drift and leaders stop trusting them.
A census and data-quality tool that catches errors before deadline day
A school administrator dreads the census because errors surface too late. A tool that validates the data against the DfE specification, flags missing or wrongly coded fields, and reconciles against the MIS ahead of the deadline turns a frantic deadline-day scramble into a manageable process. The measurable win is a return that files cleanly and defensibly, with the data problems found in advance rather than in the submission that bounces.
An admissions system built for the enrolment peak
A college outgrowing spreadsheets and email for admissions needs applications, offers and enrolment tracked as one auditable process that holds up under the induction-week surge. We build the workflow, applicants captured once, moved through the cycle, reconciled into the record system so an enrolled learner exists correctly, and we build it for the peak specifically, because admissions is exactly when an unreliable system does the most visible harm to the institution and to families.
An accessible parent portal that reduces office phone traffic
A school office buried in calls and paper consent forms wants parents to self-serve attendance, reports, messages and consent. The portal is built to the accessibility standard the school is legally bound to, integrated with the MIS so nothing is entered twice, and deliberately scoped to what parents will actually use. Done honestly it cuts inbound admin; done as a box-tick it becomes one more inbox the office has to watch on top of the phone.
How we build for education
We start from the institution’s obligations and the systems it already runs, not from the screens. Before designing anything we want to understand where the MIS or SIS sits, which statutory returns and safeguarding duties the software touches, and which administrative step is genuinely costing stretched staff their time. In education the constraint is almost always integration, data correctness and compliance, so we design for the administrator who will use this under term-time pressure, not for the demo that impresses a governing body.
We are blunt about where custom software adds value and where the MIS should stay the record. Reducing a real administrative load: reconciling data across systems, catching census errors early, taking consent forms off paper, is worth building. Rebuilding what a capable MIS already does well, or duplicating the system of record into a copy that quietly drifts, usually is not. We would rather tell you that early than build something that fights the incumbent system and the calendar and loses.
We treat integration with the MIS or SIS as the core of the work, resourced accordingly, and we plan changes around the academic calendar. The connection to the record system, and the correctness of the data that flows through it into returns and reports, are where these projects are won or lost. We plan for the awkward data, the reconciliation edge cases and the census specification from day one, and we plan releases and migrations around enrolment, exams, results and census day rather than discovering the peak the hard way.
Because we operate what we build, the people designing a returns validator or a safeguarding-adjacent access control are the ones who get called when a census will not reconcile or a permission is wrong. That concentrates the mind on the failure modes that actually matter to a school or college. The return that has to be right, the sensitive record that must not leak, and keeps us honest about trade-offs up front rather than discovering them in production during the busiest week of the institution’s year.
Regulation and compliance
Education software sits inside a specific web of statutory duties that reach into the code. Schools and colleges must submit the DfE school census and a range of other statutory data returns to defined specifications and hard deadlines, and the data has to be accurate and reconciled against the record system: the compliance lives in the correctness of the data, not in a policy beside it. Where our software touches these returns, it has to respect the specification exactly and make the data defensible before it is submitted.
Safeguarding carries its own weight. Keeping Children Safe in Education and the associated duties shape how concerns are recorded, who may see sensitive information, and how long records are kept. Any system that touches safeguarding has to be built with tightly controlled access, a reliable audit trail and careful retention, because this is among the most sensitive data an institution holds and the stakes are measured in the safety of children rather than in a defect.
Accessibility is a legal requirement. As public-sector bodies, most schools, colleges and universities are bound by the public-sector accessibility regulations, which require digital services to meet a recognised standard and to publish an accessibility statement. For anything student- or parent-facing we engineer to that standard from the start, because it is both a legal obligation and a genuine matter of inclusion for learners and families who have a right to use these services.
Data protection under UK GDPR runs across all of it, and education data includes children’s personal data, which deserves particular care around lawful basis, minimisation, retention and access. We build systems that meet these obligations, but we are engineers, not your legal, compliance or data-protection advisers. The duties around statutory returns, safeguarding, accessibility and children’s data carry real legal weight, and sign-off rests with the institution’s own leadership, data-protection and safeguarding functions. Our job is to build software that captures, evidences and retains what those obligations require, and to work alongside the people accountable for them.
Integration
The MIS or SIS is the gravitational centre for education software. A school’s management information system, or a university’s student information system, is the record for pupils, staff, attendance and assessment and the source that feeds statutory returns, so almost anything we build has to integrate with it: reading data, writing back where appropriate, and staying consistent so information exists once and correctly. We build resilient connections that cope with the realities of the incumbent system rather than pretending the institution will migrate off the record that holds its obligations.
The wider institutional estate is the other side of the problem. Finance systems, virtual learning environments, admissions tools, assessment platforms, identity and single-sign-on providers, and a long tail of departmental spreadsheets all have to be reconciled rather than ignored. In a multi-academy trust or a university that fragmentation multiplies, and the recurring engineering task is keeping data consistent across systems that were never designed to agree, which is core work, not an afterthought.
Statutory returns and reporting depend on that integration being clean. Producing a census or a report means pulling the right fields from the record system, coding them to the specification, and reconciling them so the output is complete and defensible. We build the data pipelines and validation for this deliberately, because a return assembled from inconsistent or stale data is exactly how an institution ends up with a submission that bounces on deadline day.
Identity, access and directory integration matter more here than in many sectors, because access has to be scoped to genuine role and need: a safeguarding record is not for everyone, a student’s data is not for every member of staff. We integrate with the institution’s identity and single-sign-on so access reflects real roles, and so the audit trail an investigation or a data-subject request would need is available rather than missing after the fact.
Security and data protection
Education software holds a great deal of personal data about children and young people, alongside staff data and, in safeguarding contexts, some of the most sensitive information an institution keeps. That is a serious liability and a genuine duty of care, so we build with access controls scoped to real role and need, encryption in transit and at rest, and retention limited to what a lawful basis and the institution’s policies actually support: children’s data in particular is not something to accumulate loosely.
Safeguarding data deserves stricter handling again, narrower access, clear purpose limitation, a reliable audit trail, and deliberate thought about who ever needs to see a concern or a sensitive record. This is exactly the sort of data flow that turns into serious harm when it is added without care, so we design it deliberately and conservatively rather than letting sensitive records spread across the system by default.
The term-time rhythm shapes the security and reliability picture too. Enrolment, exams, results and census day are the moments a compromise or an outage does the most damage, so we build for availability and integrity at those peaks specifically, and we treat the ability to reconstruct exactly what happened to a record (who accessed it and when), as part of the deliverable rather than something discovered missing after an incident.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation or a data-subject request would need (which matters acutely when the data subject is a child), and design access around genuine institutional roles from the start, because an over-broad permission on children’s data is not a cosmetic flaw but a duty-of-care failure.
What changes
Statutory returns that file cleanly and defensibly
Because we build to the DfE specification and reconcile against the MIS with the data quality surfaced in advance, the census and other returns are complete and correct (errors found before the deadline rather than in a submission that bounces), so an obligation that carries real weight stops being a deadline-day scramble.
Administrative load genuinely reduced, not relocated
By integrating with the record system and scoping tools to what stretched staff and families will actually use, the software takes real work off the office (data reconciled across systems, consent off paper, information shown once), rather than adding another disconnected island that needs feeding and quietly gets abandoned.
Sensitive data handled with the care the duty demands
Because access is scoped to genuine role and need and the audit trail is treated as part of the deliverable, children’s data and safeguarding records are handled conservatively and defensibly, which is a duty of care in this sector, not a compliance checkbox, and exactly where casual engineering does real harm.
What we build for education
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for education?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in education choose us
We build for the institution and its statutory duties
Most edtech ignores how much of a school or college’s software life is administration and compliance rather than pedagogy. We start from the census, the safeguarding duty, the accessibility obligation and the accurate record (the things the institution is genuinely on the hook for), and build software that serves them, because that is where the real risk and the real value sit.
We treat MIS and SIS integration as the hard part it is
The connection to the system of record, and the correctness of the data flowing through it into returns and reports, are where these projects are won or lost. We resource that from day one and build resilient integration rather than pretending the institution will migrate off the record that holds its obligations, which is what separates software that works from software that ships half-connected.
We are honest about where the MIS should stay the record
Not every administrative step needs custom software, and rebuilding what a capable MIS already does well just creates a copy that drifts. We will tell you plainly which real administrative load is worth removing and where the record system should remain the source of truth, rather than selling you software that fights the incumbent and the calendar and loses.
We operate what we build
The people who design a census validator or a safeguarding-adjacent access control are the ones paged when a return will not reconcile or a permission is wrong. That keeps us focused on the failure modes that matter to a school or college. The return that has to be right, the child’s record that must not leak, and honest about trade-offs up front, not discovering them in production during the busiest week of the year.
Related sectors
Adjacent sectors we also know.
Common questions
Will you replace our MIS, or work with it?
Work with it, almost always. Your MIS (or your SIS if you are a university), is the record for pupils, staff, attendance and assessment and the source that feeds your statutory returns, so it holds your obligations and your trust. Custom software should integrate with it, sit alongside it, or migrate carefully, never rip it out mid-term. We treat that integration as first-class engineering and build resilient connections that keep data consistent, because the record system is not going anywhere on the timescale of a single project, and duplicating it into a divergent copy is how education software quietly loses the institution’s confidence.
Can you help us get the DfE census and other statutory returns right?
Yes, and we treat the return as a data-correctness problem, not a form. We build tooling that validates your data against the DfE specification, surfaces missing or wrongly coded fields, and reconciles against the MIS ahead of the deadline, so problems are found in advance rather than in a submission that bounces on deadline day. The compliance lives in the accuracy of the data, so we build to the specification exactly and make the data quality visible early. To be clear on the boundary: we are engineers, not your statutory-returns or compliance advisers, and sign-off on what you submit rests with your own leadership and data functions.
How do you handle safeguarding data?
With the seriousness it demands. Safeguarding is a legal and moral duty under Keeping Children Safe in Education, not a feature, so any system that touches it is built with tightly controlled access scoped to genuine role and need, a reliable audit trail, and careful retention. This is among the most sensitive data an institution holds and the stakes are the safety of children, so we design those data flows conservatively and deliberately rather than letting sensitive records spread by default. Accountability for safeguarding rests with your designated leads and leadership; our job is to build software that supports the duty rather than undermines it.
Do our parent and student-facing services have to be accessible?
Yes. As a public-sector body, your institution is bound by the public-sector accessibility regulations, which require digital services to meet a recognised standard and to publish an accessibility statement. For anything student- or parent-facing we engineer to that standard from the start rather than retrofitting after an audit flags it, because accessibility is both a legal obligation and a genuine matter of inclusion, learners and families have a right to use these services, and building it in from the beginning is far cheaper and better than bolting it on later.
How is this different from building a learning platform or e-learning?
It is a different problem, and we treat it as one. This work is about the institution and what it is legally and operationally on the hook for: the accurate student record, admissions, timetabling, assessment and reporting, safeguarding, statutory returns, accessibility and the administrative load on stretched staff. Course delivery, content authoring, learner engagement and the learning experience itself sit in e-learning and belong with our learning-platform work. Keeping the two separate matters: the institutional record and its compliance obligations are a distinct discipline from designing how learning is delivered, and conflating them is how projects lose focus on the duties that actually carry legal weight.
Building for education?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if education is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.