Mo.

Building a Helpdesk for a Multi-Academy Trust

Mo/February 24, 2025/5 min read
Building a Helpdesk for a Multi-Academy Trust
Staff Helpdesk Interface

Streamlining IT Chaos: Building a Helpdesk for a Multi-Academy Trust

Keeping IT Support From Crumbling

Let’s face it: IT support in schools can be a mess. For a Multi-Academy Trust juggling multiple locations and a growing crew of staff, that mess gets exponential. The old helpdesk system we were stuck with was a relic—clunky, impossible to keep up, and about as flexible as a brick. Tickets got lost in the void, response times dragged, and there was no way to tell what was fixed or who was drowning in requests.

So, we decided to scrap it and build something better. I teamed up with two other developers to whip up a custom helpdesk from scratch—one that could handle the chaos, scale with the Trust, and make life easier for the IT technicians and staff across all the schools.

The Squad and My Piece of the Puzzle

Here’s who was in the trenches:

  • Two frontend devs (me included)—we tackled the interface, ticket features, and hooked everything up to the backend.
  • One backend dev—handled the API guts and database magic.

As one of the frontend developers, I was responsible for:

  • Crafting a slick, no-nonsense interface that didn’t make people want to throw their laptops out the window.
  • Wiring up the backend API for tickets, logins, and updates without breaking a sweat.
  • Keeping things snappy—smooth state handling and quick rendering, no lag allowed.
  • Syncing with the backend guy—figuring out API handshakes and squashing bugs together.

Here’s the rundown of how we pulled this off, the headaches we hit, and the calls we made to get it over the finish line.

The Tech We Bet On

We didn’t just wing it—picking the right tools was half the battle. We needed a setup that could take a beating, stay secure, and not turn into a maintenance nightmare.

Frontend: React

React was our go-to for the frontend. It’s fast, modular, and lets you build something that doesn’t feel like a chore to use. My job here was:

  • Refactoring components for consistency and reusability, ensuring a cohesive and maintainable UI
  • Plugging into the backend API for ticket tracking and updates on the fly.
  • Optimising performance with efficient state management to handle high ticket volumes smoothly.

Backend: C# (.NET)

The backend ran on C# with .NET—rock-solid and secure. It took care of:

  • Logins and permissions, so the right people got the right access.
  • Ticket logic—creating, assigning, and tracking without hiccups.
  • Stashing data in MySQL, keeping everything tidy and searchable.

I worked closely with the backend developer, pinning down API details and ironing out any mix-ups.

Database: MySQL

MySQL was the backbone for data. Reliable, fast with the right indexes, it held:

  • Tickets and their statuses—open, in progress, closed.
  • Implementing user roles to restrict access and protect sensitive information.
  • Past records for digging into trends or reports later.

The backend developer optimised queries to ensure fast searches, even as the ticket volume increased.

Security: Locked Down

No one’s getting in without a ticket (pun intended). We used:

  • Azure Active Directory for single sign-on if it was there—staff loved not juggling extra passwords.
  • JWT and session auth for the API to keep requests legit and data safe.

Azure DevOps: The Glue

Azure DevOps kept us sane. It handled:

  • Task tracking and sprints, so we knew who was doing what.
  • Git for version control.
  • CI/CD pipelines—automated builds and deploys.

What Mattered Most

We didn’t just slap code together—there were some big boxes to check to make this thing work.

  1. Making It Easy and Fast

    Staff and IT technicians would use this daily, so it had to feel good and move quick:

    • Lazy loading and code splitting to ditch the loading spinner.
    • Virtual lists to scroll through hundreds of tickets without a stutter.
    • A simple interface—create or update a ticket quickly.

  2. API and State Smarts

    The frontend and backend had to stay in sync:

    • Handled state management using React's built-in state (useState, useEffect) and context (useContext) where needed.
    • Pagination ensured efficient data handling, keeping ticket loads minimal and response times fast.

  3. Who Sees What

    Security wasn’t optional:

    • Regular staff can only view and update their own tickets, ensuring privacy and limiting unnecessary access.
    • IT techs have full visibility—assigning, modifying, and closing tickets as needed.
    • User authentication is handled via Azure AD
    • Actions like ticket updates, assignments, and closures are logged for accountability and troubleshooting.

  4. Deploying Without Drama

    Azure DevOps CI/CD made it smooth:

    • Builds and deploys on autopilot.
    • Separate setups for staging, testing, and live—no surprises.
    • Logs and monitoring to catch hiccups fast.

The Wrap-Up: What We Learned

Building this helpdesk was a grind, but it paid off. Going from a creaky old system to something slick and scalable turned IT support from a headache into a breeze.

Big Wins:

  • Scalability: React, C#, and MySQL managed large numbers of users with ease.
  • Teamwork: Frontend, backend, and IT staff all pulled together.
  • Problem-Solving: Nailed API hiccups, UI speed, and access control.
  • User Love: Staff actually liked using it—huge W.
  • DevOps: Smooth CI/CD workflows kept us on track and stress-free.

The Bottom Line

This project not only improved IT support for the Trust but also strengthened my full-stack development skills, particularly in frontend development, API integration, and performance optimisation. As I move forward, I look forward to applying these skills to new challenges and opportunities in software development.