Student Central — University Matching Platform
The Context
International student recruitment in the UK has traditionally relied on agents, education fairs, and generic university directories. For students — often navigating the process from overseas — the landscape is overwhelming: hundreds of institutions, limited tools for determining genuine fit, and a system that rewards volume over compatibility. For universities, reaching the right candidates means competing through the same crowded channels as everyone else.
Student Central identified an opportunity to invert this dynamic. Rather than students searching through directories, the platform would work in reverse: students create a single profile, and UK universities browse a pre-qualified, anonymised registry of candidates matched to their programmes and entry requirements. A two-sided marketplace where both parties benefit from better information and less noise.
The Brief
Student Central commissioned Rocking Tech to design and build the platform from scratch. The engagement began with an initial meeting that ran to five hours — not a formal workshop, but an open conversation where the business model, user journeys, and technical possibilities were explored together. By the end of that session, the shape of the platform was clear: who it served, how the matching logic needed to work, and what the architecture had to support.
That conversation shaped every subsequent decision. It surfaced the complexity of the matching logic early and identified the four distinct user types the platform needed to serve. It also led to a key recommendation from Rocking Tech: that every form field, matching parameter, and content element should be admin-configurable from day one — giving the client the freedom to experiment with different question structures and scoring approaches without requiring developer involvement for each change.
The technology choice was Laravel — a decision that proved its value across two and a half years of continuous development. The framework’s migration system absorbed 142 database schema changes without disruption. Its Eloquent ORM supported 50 interconnected data models as the platform grew. And Laravel Nova provided an administration layer sophisticated enough to give the client full operational control.
The Matching Engine
The centrepiece of the platform was a recommendation engine that evaluated every university in the database against each student’s profile across eight weighted parameters. The concept of matching students to universities based on their preferences was central to Student Central’s vision. The technical solution — cross-reference scoring matrices, weighted coefficients, conditional parameters, and explainable outputs — was Rocking Tech’s contribution, translating a business idea into a system that could score, rank, and explain at scale.
Location type matched a student’s preference for urban, campus, or rural settings against each institution’s classification. This was not a binary filter. The scoring matrix defined a value for every intersection of student preference and university setting — so a student who preferred an urban environment would still receive a weighted score for a campus university, rather than having it excluded entirely.
University type scored across institutional categories including Russell Group, post-1992, and specialist institutions. University size evaluated preferences from small and specialist to large multi-faculty. Entry difficulty was calibrated across a five-point scale. Tuition fees applied graduated penalty scoring for institutions exceeding the student’s stated budget, with a configurable floor to prevent viable options from being eliminated at the margins.
Subject specialisation handled multi-match scoring — where a university offered several relevant programme areas, the engine took the strongest match rather than averaging across weaker ones. Work experience requirements and GMAT score thresholds were conditional parameters, applied only when relevant to the student’s chosen degree pathway.
Each parameter drew from its own database-driven scoring matrix, managed entirely from the admin panel. The client could adjust weighting coefficients — the relative importance of each factor in the overall score — without touching code and without a deployment cycle.
Students could additionally select one factor as their top priority. This applied a multiplier to the chosen dimension and a corresponding reduction to the others, meaning two students with identical profiles but different priorities would receive meaningfully different recommendations.
Each university’s score came with a breakdown: which parameters contributed what, how the student’s priority selection affected the result, and why a particular institution ranked where it did.
The Platform
The matching engine sat within a two-sided platform serving four distinct user types, each with different permissions, interfaces, and workflows.
Students registered via email, Facebook, LinkedIn, or WeChat and completed a dynamic profile form. Every field on the form — its type, label, required status, visibility rules, grouping, and display order — was managed from the admin panel. The client could add, remove, or restructure questions at any time without code changes. Once their profile was complete and validated, students could self-publish to the anonymised registry. They could unpublish, edit, and republish at any time, with each transition going through the same validation process. The platform recorded every status change as auditable history.
University representatives registered with an institutional .ac.uk email address, validated on both the frontend and backend. After verifying their account and accepting the platform’s terms and conditions through an online signature workflow, representatives could browse the student registry, apply filters across any combination of parameters, and build shortlists of candidates. The registry displayed anonymised profiles by default. Full student details were unlocked only after T&C acceptance — a deliberate design decision to protect student data while giving universities meaningful access to pre-qualified candidates.
Referral associates had a dedicated dashboard showing the status of students they had referred, structured as a conversion funnel: account created, profile submitted, profile published, enquiry received.
Administrators controlled the entire platform through Laravel Nova — managing users, form fields, matching parameters and weighting tables, content pages, service packages and pricing, email notification templates, and granular role-based access permissions for other team members.
The student registry used reactive filtering with no page reload. University representatives could combine multiple filter parameters — including fields visible only to administrators and university users, hidden from students — and see results update instantly. Every filter query was logged with its parameters in a structured format, capturing how universities searched, which criteria they prioritised, and which combinations led to shortlist additions.
Student documents — transcripts, certificates, uploaded CVs — were stored on a dedicated server, physically isolated from the application infrastructure. This was a deliberate security architecture decision by Rocking Tech: sensitive personal documents should not sit alongside application code and user session data. The platform recorded which document types had been submitted and displayed status indicators, but the files themselves were accessible only to the Student Central team through dedicated credentials. A CV generation feature added in a later phase allowed the platform to produce a formatted two-page PDF from each student’s profile data in real time.
Integrations included Stripe for tiered service payments, Hubspot for automatic CRM contact creation and field synchronisation, Mailgun for transactional email via background queues, social authentication via Facebook, LinkedIn, and WeChat APIs, and Google Analytics with configured conversion goals and funnels.
How It Grew
The project began as a minimum viable product — and staying minimal required discipline. The initial brief included features that would have added weeks to the build without serving the core hypothesis. Rocking Tech’s recommendation was to strip back to the one thing that mattered: does the matching engine produce results that students and universities find useful? Everything else could follow once that was validated.
Each subsequent phase built on the architecture established at the outset — the migration-based database design, MVC structure, and deployment pipeline meant the platform could absorb substantial new functionality without rewriting existing systems.
The MVP established the foundation: authentication with social login, personal accounts, a university catalogue, the questionnaire-driven matching algorithm, a blog with content migrated from two legacy websites, the admin panel, and production deployment with a parallel development environment for testing.
This phase introduced the two-sided platform model under the Student Central name. It added extended student data collection with secure document uploads, a redesigned landing page, university representative roles with institutional email verification, advanced email notifications, a messaging centre, the student registry with reactive filtering, the full publication and shortlisting workflow, and a migration to Laravel Nova for administration.
Iteration refined the user experience: frontend navigation, a tiered services page, a contact page with enquiry routing, Google Analytics goal tracking, Hubspot CRM integration, new form question types, improved validation with smooth-scroll error handling, and the self-publishing profile workflow that allowed students to manage their own registry visibility.
Scale focused on infrastructure and depth: codebase refactoring for long-term maintainability, a Laravel framework version upgrade, server infrastructure improvements, deeper Hubspot API integration with bulk synchronisation, the associate referral dashboard, a university information section with data imported from Google Sheets, student-side university shortlisting, and Stripe payment integration.
Simplification streamlined student onboarding in response to real usage patterns: a new single-page form reducing the initial commitment to five core fields plus a CV upload, refined admin dashboard views, granular role-based access for the Nova panel, and the automated CV PDF generator.
Laravel (PHP), MySQL, Laravel Nova, Vue.js components, Less preprocessing with BEM methodology, jQuery, Docker with Ansible deployment, DigitalOcean hosting, Mailgun, Stripe, Hubspot API, Google Analytics.
142 database migrations absorbed without disruption. 50 interconnected Eloquent models. Two and a half years of continuous development on the same architecture.
The platform operated across multiple international student recruitment cycles, serving students and university representatives through the full matching, shortlisting, and enquiry workflow.
The platform’s technology was a key part of a successful Innovate UK bid for further development of the service.
The Student Central project predated both the widespread availability of AI development tools and Rocking Tech’s formalised Discovery Sprint process. The deep initial conversation, iterative architecture, and phased build approach that made it successful are now the foundation of how we work with every platform client.