Building Assessment and SEND Software for UK Schools: How We Built E2P+SEND

A teacher records a two-minute observation of a child during free play. That observation needs to be tied to a specific developmental outcome, a specific framework stage, and — if the child has an Education, Health and Care Plan — a specific SEND review cycle that's legally required to hold up under audit. Do that correctly, at scale, across a whole school, and you've solved one of the genuinely hard problems in UK EdTech. Do it in a spreadsheet, and you've built a liability with a due date.

That's the problem E2P+SEND was built to solve. It's a UK early-years-to-primary assessment and SEND (Special Educational Needs and Disabilities) management platform, developed with educators who have real UK senior-leadership experience, now live at primaryessence.com. This is what we learned building software that has to satisfy both a classroom teacher on a Tuesday morning and a statutory audit six months later.

Why is assessment software for UK schools a harder problem than it looks?

Early years and primary assessment in the UK runs on frameworks with hundreds of individual outcomes, tracked per child, across every stage from nursery through the end of primary school. That's the baseline. Layer SEND provision on top — multi-stage, strictly regulated, involving EHCP reviews that legally require accurate, evidenced records — and you have two compounding sources of complexity rather than one.

Most schools we looked at were managing this across spreadsheets, paper logs, shared drives, and email threads. Not because the staff were disorganised — because nothing designed for this specific problem existed. General-purpose education software doesn't understand that "SEND review" means a formal, multi-stage, auditable process, the same way generic small-business tools don't understand industry-specific workflows in any vertical. The gap between "software that stores data" and "software that understands SEND provision" is where E2P+SEND had to live.

Designing for four different jobs, one platform

The user base for E2P+SEND isn't one persona — it's four, each with a genuinely different job to do. Classroom teachers doing day-to-day observation. Senior leadership teams (SLT) needing whole-school and whole-cohort views. SENCOs running formal SEND processes with statutory obligations. And external professionals — therapists, consultants, local authority staff — who need access to specific children's records without access to everything else.

Permissions here aren't a settings-page nicety; they're the difference between a compliant platform and a data-protection incident. A SENCO's workflow and a classroom teacher's workflow are genuinely different products wearing the same login screen. We built role-based access that reshapes the interface itself depending on who's logged in — not just hiding a button here and there, but presenting a role-appropriate view of the same underlying data. That's a different engineering discipline from building one UI and gating features behind permission flags, and it's the same discipline we bring to any platform with real access-control requirements, from clinical research to healthcare SaaS.

The architecture: five modules, one dashboard

We structured the platform's core around five connected modules hanging off a single dashboard, rather than one monolithic app trying to do everything at once: Student Profiles (personal and medical/care information), Assessment (point-in-time framework logging), Progress Analysis (group trends and individual trajectories over time), SEND Management (EHCP reviews and intervention logs), and an Evidence Gallery (photo and video evidence, tagged to the relevant outcome).

Getting that information architecture right — deep, nested framework structures presented through a flat, approachable navigation — was the foundation everything else sat on. Four design problems recurred constantly across those five modules, and we solved each one the same way, every time it showed up:

Complex information got progressive disclosure — hide secondary data until it's relevant to the task in front of the teacher, instead of surfacing everything a screen could theoretically show. Data-heavy screens got custom table components with sticky headers and contextual side panels, so a teacher can edit a record without a full page reload breaking their train of thought. Different workflows for different roles got the role-based permission system described above. And global consistency across 200+ unique views required a real, reusable component library built once rather than each screen designed in isolation — the same principle behind any SaaS platform built to scale past its first dozen screens.

Replacing the SEND email thread with an actual system of record

The specific failure mode we were most determined to fix was SEND's dependence on email threads and paper trails for multi-stage approval and review. It's not just inefficient — it's a compliance risk. If a school can't produce a clean audit trail for an EHCP review when a local authority or Ofsted asks for one, "we know it happened" isn't good enough.

We built structured multi-stage review and approval workflows directly into the platform — EHCP review cycles and intervention logging with a single source of truth and an audit trail by construction, not by discipline. That distinction matters: a system where the audit trail exists because the workflow requires it is fundamentally more reliable than one where the audit trail exists because someone remembered to keep good records.

Why does software fatigue decide whether a school platform actually gets used?

Teachers are already running a school MIS, a safeguarding platform, a communications tool, and whatever their local authority mandates on top. The single biggest risk to E2P+SEND wasn't a missing feature — it was becoming one more piece of software a teacher resents opening. So usability wasn't a polish pass at the end; it was a design constraint from day one, with the explicit goal of feeling closer to a consumer app than an enterprise system.

That's also why parent engagement was built in rather than bolted on. Parents get their own access to view and contribute to their child's learning record — moving assessment and SEND from something that happens to a family to something they're genuinely part of. Software that's simple enough for a busy parent on a phone is, not coincidentally, also simple enough for a busy teacher.

Security was a schema-level decision, not a checklist

Child data — including medical and care information tied to SEND provision — is among the most sensitive categories of personal data a piece of software can hold. We treated protection as foundational rather than a compliance pass before launch: automated encryption at rest, deliberate key rotation, and a data-protection posture built to GDPR and UK Data Protection Act standards from the schema up. The production pipeline ran UX design → UI/design system → frontend development → backend logic → data migration → QA testing → deployment, with "secure by design" enforced at the backend-logic stage — the same order-of-operations discipline we've argued for in every regulated software build we take on, because retrofitting compliance after the architecture is set is how you end up rebuilding the architecture.

What building for UK schools taught us

Domain expertise from the client changes what "correct" means. E2P+SEND was built with educators who've run UK school senior leadership themselves — not just consulted on requirements, but shaped what the product actually needed to do. That's a different, better input than a generic requirements document.

Permissions are a product decision, not a settings feature. When four user types have four genuinely different jobs, the interface has to change per role, not just the visible feature set.

Compliance-by-design and usability aren't in tension — they're the same discipline applied twice. A workflow that makes the audit trail automatic is the usable version, because it removes a manual step from the teacher's day rather than adding one.

"Feels like a consumer app" is a legitimate technical requirement in education software, not a nice-to-have. Adoption in schools lives or dies on whether busy staff will actually use the tool without friction, regardless of how correct its data model is underneath.

Thinking about building assessment, SEND, or compliance-heavy education software?

If you're building software for a regulated environment where the audit trail matters as much as the feature — SEND, safeguarding, clinical research, healthcare — the order of operations is what determines whether it holds up: design the compliance posture and the audit trail into the data model first, and let the UI serve that structure rather than the other way around. That's what we did on E2P+SEND.

We build education and compliance-heavy SaaS platforms for schools, healthcare providers, and regulated organisations across the US, UK, Australia, and the EU — and we're happy to give you an honest read on your specific compliance requirements before anyone quotes a number. If that's the conversation you need, tell us what you're building.

E2P+SEND is live across UK primary and early-years settings at primaryessence.com, replacing spreadsheets and email threads across 200+ unique views with a single system covering assessment, EHCP reviews, and reporting. Read the full case study →