Services
Four connected offerings, scoped to what a small institution actually needs — no enterprise platform, no army of consultants, no lock-in.
1 · Bespoke student information systems
A single source of truth for student data, covering the full lifecycle: application and audition (including document and performance-video upload, with payment handled by a hosted gateway), offer, registration and enrolment, attendance and engagement, assessment, progression and awards, through to completion and graduate outcomes.
- One student, one record. An identifier graph links applicant numbers, HESA identifiers, ULNs and email addresses over time, so the record survives re-enrolment, category changes and system transitions. Ambiguous matches are never merged automatically — they queue for human review.
- Your tenancy, your identity platform. Delivered into your own Microsoft Azure subscription, with sign-in through Microsoft Entra ID and role-based access — least privilege by default, and no one able to approve their own changes.
- Sign-off where it matters. Students update their own contact details directly; identity and eligibility changes route to the registrar; marks entered late or changed after the window route to academic leadership. Every change lands in a tamper-evident audit trail — who, when, what, why.
- Assessment as it really happens. Grades and feedback imported from your LMS or Turnitin where applicable, entered directly for practical and performance-based assessment, with an explicit provisional → confirmed → corrected lifecycle — and every downstream output regenerates when a correction lands.
- Self-service for students. Students securely see their own record — programme, progression, assessment outcomes — update designated fields, and submit absence requests through the same audited workflows, on a surface aligned with OEAPI conventions for future interoperability.
- Forms without programmers. Fields, stages, validation rules and sign-off policies are versioned configuration that trained staff change themselves — staff-led change with an audit trail, not a proprietary form-builder nobody can inspect.
- Retention that follows your policy automatically. Per-cohort retention schedules encoded from your data-retention policy, reminders when retention expires, erasure workflows with a recorded lawful-hold override, and cryptographic erasure so erased data is dead in every backup too.
2 · Statutory returns & data quality
Small OfS-registered providers carry the same reporting duties as large universities, with a fraction of the staff. We build systems that treat HESA as it really is: continuous, changing, and always ending in human judgement.
- The full returns family: HESA Student Record (Data Futures, including the in-year collections as HESA finalises them), HESES, Graduate Outcomes, OfS Transparency Information, Aggregate Offshore, and NSS extraction and analysis.
- Captured right once. Fields validate against HESA valid entries and cross-field rules at the point of entry, so return-quality data is captured upstream instead of cleansed every autumn.
- Your quality report before HESA sees it. A quality-rule engine reproduces HESA Data Platform behaviour — including tolerance (Inside/Outside) statuses — rebuilt from the published specifications and versioned per collection year.
- Human sign-off, by design. Schema-valid XML with the quality report behind it, failures triaged, overrides recorded with reasons, sign-off captured, and every submitted return archived. We do not pretend to one-click compliance — HESA operates no system-to-system upload, and in-year reporting makes review more important, not less.
- Specification as data, not code. HESA's requirements change constantly — around a third of the specification in a typical cycle. We hold the specification as versioned data with cross-version diffing, so a new collection year is a bounded, testable update rather than a rebuild.
- Prove it before switching. Nothing statutory moves to a new system until it has produced the same results as your current process, running alongside it — and there is always a safe way back.
3 · Reporting, benchmarking and dashboards
Reporting a non-technical member of staff can drive — because board papers should not require a developer.
- Staff pick the criteria — cohort, year, characteristic, module — generate reports themselves, and export board-ready tables and charts.
- Every published figure carries an audit table: the row-level derivation that makes any number checkable when questioned.
- Published OfS and HESA datasets are imported and versioned, then linked to your internal data for benchmarking against the sector or a named peer group.
- Access and Participation Plan dashboards track targets, waypoints and RAG status; outputs support Boards of Examiners, NSS and Graduate Outcomes analysis, TEF readiness and quality-assurance processes.
4 · Continuity & governance
Institutional knowledge should not walk out of the door when one person does — and we apply that standard to ourselves as strictly as to anyone else.
- Documentation as a primary deliverable, much of it generated from the system's own configuration, so documents cannot silently drift from behaviour.
- A perpetual licence to the source code, configuration, data structures and documentation — vesting as each milestone is accepted, surviving the end of any agreement, with no annual fee.
- The exit ramp: every data store exports to plain, documented formats at any time, without our involvement. A standing acceptance criterion, not a promise.
- Knowledge transfer, acceptance-tested: the project is not complete until named staff perform the key operating tasks unaided — and a nominated technical successor can rebuild a working environment from the repository and documentation alone.
How we work
- Acceptance criteria agreed in advance. Every milestone has written accepted-when criteria; payment falls due on acceptance, not on effort.
- Working software, not slideware. We demonstrate hands-on, in a live environment, using invented data and published datasets only — and we would rather you tried to break it than took screenshots on trust.
- Proportionate scope. We recommend the smallest intervention that solves the problem, and we will say so when a bigger system is not justified.
- Deliberately boring technology. A web application and a relational database, minimal third-party dependencies — because every dependency is a supply-chain and continuity risk for a small institution.
- Transparent pricing structure. Fixed prices linked to accepted milestones, a published day rate for changes agreed before work starts, and no annual licence line — ever.
- Data protection by default. Written data-processing agreements, data minimisation, and client personal data never in code repositories, demonstrations or marketing. Details on our trust & governance page.