Digital platforms for colleges, universities and councils
Most public sector website projects are not really website projects. The site is the visible part. What the organisation is actually buying is a route from a search result to an application, in two languages, accessible to everyone, connected to the systems that already hold the data.
We design, build, integrate and support digital engagement platforms, and we treat accessibility, bilingual delivery and integration as requirements rather than extras.
From discovery to the support that follows go-live
The work that decides whether a platform succeeds happens before launch and continues long after it.
Discovery and content design
Research with the people who actually use the site: prospective learners, parents, current students, employers and the staff who publish content. Course and service information modelled as structured content rather than pages, so the same data drives search, listings and integrations without being retyped.
Accessible build to WCAG 2.2 AA
Semantic markup, keyboard operation, visible focus and tested colour contrast built into every component from the first sprint. Automated accessibility checks in the pipeline so regressions fail before they ship, manual and screen reader testing for what automation misses, an independent audit before go-live, and the accessibility statement the 2018 regulations require.
Bilingual Welsh and English delivery
Both languages modelled into every content type from the start, so Welsh is never an afterthought that drifts out of date. Language choice remembered, navigation and URLs working in both languages, and forms, error messages, automated emails and search included rather than left in English.
Integration with the systems you run
Student records, CRM, admissions and applications, course data, single sign on and payments, connected through a defined integration layer with logged and retryable calls. Clear ownership of each piece of data, defined sync behaviour, and graceful degradation so an outage elsewhere does not take the website down with it.
Personalisation and AI where it earns its place
Course search that understands plain language, guided answers grounded in your own published content with sources shown, and drafting or translation support for editors with a human review step. We keep AI away from anything that has to be authoritative or auditable, and always leave a clear route to a person.
Hosting, support and improvement
Monitored UK hosting with agreed uptime, security patching, an agreed route for raising issues with response times attached, and analytics reviewed against the outcomes that matter: enquiries, applications and enrolments.
A method, phase by phase
This describes how we would run work of this type. It is method, not a completed contract.
- 1
Discovery
Users researched, current analytics and search data reviewed, content audited, systems and data owners mapped, and success measures agreed before anything is designed.
- 2
Content model and architecture
Content types, bilingual structure, integration points and hosting approach defined and signed off, so the expensive decisions are made on paper rather than in code.
- 3
Design and prototype
Accessible component designs and a working prototype tested with real users, including users with access needs and Welsh speaking users, before the full build starts.
- 4
Build in increments
Working software shown every two weeks, with automated tests and accessibility checks running on every change, so progress is visible rather than reported.
- 5
Content migration and training
Content migrated with an editorial review rather than copied wholesale, editors trained on the CMS, and documentation handed over.
- 6
Testing and go-live
Independent accessibility audit, security testing, performance testing and user acceptance testing, then a planned launch with rollback, redirects mapped from the old site, and support on hand.
- 7
Support and improvement
Monitored hosting, agreed response times, analytics reviewed against the agreed measures, and a prioritised improvement backlog owned jointly with you.
Set up for public sector procurement
We are an SME, so the people who answer a tender are the people who deliver the work.
We build and run our own software products, so the platform we deliver for you is built the way we build for ourselves: tested, monitored, patched and supported rather than handed over and forgotten.
On data protection we expect to agree UK GDPR roles, hosting location, sub-processors and a data protection impact assessment before contract rather than after, and to write them into the contract rather than into a slide.
On accessibility and Welsh language we expect the duties to be evaluated, so we plan for an independent audit and qualified translation from the start rather than pricing them as options.
Frequently asked questions
What does a digital engagement platform mean in practice for a college?
It means the website stops being a brochure and starts being the front end of the college processes. A prospective learner searches a course, sees accurate availability, starts an application, and the college sees that person in its CRM rather than in an inbox. A current learner finds term dates, support services and their own information without ringing reception. Staff publish and update content themselves without waiting on a developer. The platform is judged on whether enquiries turn into applications and applications into enrolments, so the integrations and the content model matter more than the homepage design.
How do you meet the public sector accessibility regulations?
By building to WCAG 2.2 AA from the start rather than testing against it at the end. Components are built with semantic markup, keyboard operation and visible focus, colour contrast is checked as designs are produced, and templates are tested with a screen reader as they are built. Automated checks run in the build pipeline so a regression fails before it ships, and manual testing covers what automation cannot see. We also expect an independent audit before go-live, and we write the accessibility statement the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require, including any known issues and the plan to fix them.
How is a bilingual Welsh and English site handled properly?
Bilingual delivery has to be designed in, not bolted on. Every content type is modelled with both languages from the start, so Welsh is never a second class copy that falls out of date. Language choice is remembered, URLs and navigation work in both languages, and the Welsh interface is complete rather than partially translated. Search, forms, error messages, automated emails and documents are all in scope, because those are where bilingual sites usually break. Translation is carried out by qualified translators with a review step, and the publishing workflow flags where a Welsh version is missing before an English page can go live.
What integrations does an education platform usually need?
Typically the student records system, the CRM, the application or admissions route, the course data source, single sign on, and the payment provider. The practical questions are which system owns each piece of data, how often it syncs, and what the site does when the other system is unavailable. We prefer a defined integration layer with logged, retryable calls over direct coupling, so that an outage in one system degrades the site gracefully instead of taking it down, and so that a future system change does not mean a rebuild.
Where does AI genuinely help, and where does it not?
It helps where there is a large body of accurate content and a repetitive question: course search that understands plain language, guided answers about entry requirements or funding, drafting support for content editors, and translation drafts that a qualified translator then reviews. It does not help where the answer must be authoritative and auditable, such as an admissions decision or a funding entitlement, and it is a liability if it is allowed to invent answers. Our approach is to ground anything user facing in your own published content, show the source, keep a human in the loop for anything consequential, and make it straightforward to reach a person.
What happens after go-live?
The platform is supported and improved rather than handed over and forgotten. That means monitored hosting with agreed uptime and response times, security patching, an agreed route for raising issues, training and documentation so your staff can run their own content, and analytics reviewed against the outcomes you care about. Improvement work is prioritised with you rather than delivered as a fixed list, because what needs changing after three months of real traffic is rarely what anyone predicted before launch.
Talk to us about a digital platform
For college and university marketing, admissions and IT leads, and council digital teams. Tell us what the platform has to achieve and what it has to connect to.
What happens next
- A conversation with the people who would deliver the work
- A short written note of scope, approach and assumptions
- A fixed or capped proposal where the scope allows
Existing customer? Contact support